Workday Banks and Settlement Accounts: Multi-Currency Cash Management and Forex Revaluation Automation

Multi-currency cash management is where treasury operations and financial accounting collide inside a Workday tenant, and where configuration gaps have the most direct financial consequences. A bank account defined with the wrong accepted currency list routes a supplier payment through a currency conversion that was not intended. A revaluation rule configured without a reversal setting produces cumulative unrealised gain or loss entries that overstate balance sheet exposure. A settlement run that processes ahead of the bank statement load creates reconciliation exceptions that take hours to investigate. None of these are product defects. Each one is the result of a configuration decision made without a complete understanding of how the Banking and Settlement functional area interacts with the multi-currency accounting model.

This article covers the technical architecture of Workday’s bank account object, the settlement engine, the multi-currency currency acceptance and conversion model, bank statement reconciliation automation, and the foreign currency revaluation process. It is written for treasury, finance, and Workday configuration professionals who are responsible for the operational accuracy of cash management in a live Workday Financial Management environment.

The Bank Account Object: Currency Configuration and Usage Controls

Every bank account in Workday is defined as a distinct object with its own currency designation, known as the Account Currency. As documented in Workday’s Global Country Configurations Catalog, funds are stored in the bank account and converted to the applicable currency when transferred into another bank account within Workday, using the account currency as the reference point. Every bank account can also specify which additional currencies it is willing to accept for transactions, and when no accepted currencies are explicitly defined on the bank account record, the account accepts all currencies.

That default behaviour of accepting all currencies is one of the most operationally significant default settings in the Banking and Settlement functional area. In a production environment with multiple legal entities, multiple bank accounts denominated in different currencies, and strict treasury policies about which accounts handle which payment currencies, leaving the accepted currencies list unpopulated means that any payment originating from the tenant can be routed to any bank account regardless of currency, with Workday performing the conversion silently using the exchange rate in effect at the time of the settlement run. For treasury teams that have negotiated specific FX terms with banking partners for specific account-currency combinations, this default undermines the operational structure they have built outside the system.

The Workday bank account record carries a comprehensive set of usage controls that determine which transaction types each account can process. As documented in the Cash Management Web Service schema, these flags include Used by Cash, Used by Customer Payment, Used by Expense Payments, Used by Payroll, Used by Supplier Payments, and Used by Intercompany Payments, among others. Each flag is an independent boolean that must be set explicitly to enable the corresponding transaction type. A bank account that has not had the Used by Supplier Payments flag set cannot be selected as the settlement account for a supplier payment run, regardless of whether it has the correct account currency and is accessible to the right legal entity.

The combination of the account currency, the accepted currencies list, and the usage flags creates the effective routing logic for every payment processed through the settlement engine. Getting these three layers of configuration right is a prerequisite for the settlement run producing the payment file that treasury actually intends to send to the bank. For multi-entity, multi-currency environments, this configuration must be validated for every bank account in scope across every legal entity, not just the primary operating entity.

Additionally, the Bank Account record supports the Bank Identifier Code (BIC) and IBAN fields for cross-border electronic payment routing, the Reconciliation Rule Set that governs automated bank statement matching, and the Automatic Reconciliation Type that determines whether statement lines are matched to Workday transactions automatically or require manual intervention. These configuration choices directly determine how much manual effort the reconciliation process requires after each bank statement is loaded, and they must be designed with the specific transaction mix of each bank account in mind.

The Settlement Engine: Architecture, Run Sequence, and Payment File Generation

Workday operates a single settlement engine across all payment types: procurement, expenses, grants, finance, and payroll. As documented in Workday’s public sector financial management datasheet, this settlement engine provides oversight into all transaction types, shows real-time cash balances, and enables effective decisions about funding, paying, and collecting money. The single engine architecture means that payroll settlements, supplier payment runs, and expense reimbursements all pass through the same payment processing framework, with the same security model, the same approval controls, and the same accounting journal generation logic.

A settlement run in Workday selects all approved transactions that are ready for payment as of the run date, groups them by payment type and bank account, generates the payment file, and creates the accounting journals that record the cash reduction against the relevant liability accounts. The run sequence matters for multi-currency environments because the exchange rates applied to cross-currency payments are pulled from the currency rate table at the time the settlement run executes, not at the time the original transaction was entered. A supplier invoice entered at a EUR to USD rate of 1.08 will be settled at whatever EUR to USD rate is current in Workday’s currency rate table at settlement time. If treasury maintains the rate table manually and updates it weekly rather than daily, the settlement amount in company currency may differ from the invoice amount by more than the operational tolerance.

This intersection between settlement timing and exchange rate table maintenance is where many multi-currency cash management problems originate in Workday environments. The Currency Conversion Rates API operation available through the Financial Management web service exposes the currency rate data structure in Workday, including the effective timestamp, from and target currencies, rate type, and the currency rate value. Organisations that need daily or intraday rate updates should use this API to automate rate loading from a treasury management system or a market data provider, rather than relying on manual entry. The frequency of rate updates must align with the frequency of settlement runs to ensure the accounting journals generated at settlement reflect rates that treasury has validated.

The payment file formats generated by the settlement engine are determined by the configuration on each bank account and the payment type definitions within Workday. Supported electronic payment types include ACH for US domestic payments, SEPA Credit Transfer and SEPA Direct Debit for European transactions, GIRO for Asian markets, wire transfer formats for cross-border payments, and country-specific electronic formats for other jurisdictions. The format of the output file is configured in Workday’s payment format setup, and it must match exactly what the receiving bank’s integration platform expects. A format mismatch at this stage does not generate an error within Workday. The settlement run completes successfully and the payment file is generated. The error surfaces only when the bank’s payment processing system rejects the file, which may not happen until the following business day, creating a delay in payment that the supplier or payee experiences immediately.

For organisations integrating Workday with banking partners through direct host-to-host connectivity or SFTP-based file transmission, the integration architecture patterns available in Workday for XML-based financial data transformation are directly applicable to payment file generation and bank statement loading. The transformation logic that maps Workday’s internal data structures to the bank’s required file format is a critical integration layer, and it must handle currency fields, amount formatting conventions, and date format requirements specific to each banking partner and payment type.

Bank Statement Loading and Reconciliation Rule Configuration

Bank statement reconciliation in Workday operates in two modes. The first is Quick Entry, in which a user manually selects the Workday transactions that correspond to each line on the bank statement. The second is Bank Statement Load, in which the bank statement is imported into Workday as a structured file and the system applies configured reconciliation rules to automatically match statement lines to recorded Workday transactions. For most production environments with significant transaction volume, the Bank Statement Load method combined with well-designed reconciliation rules reduces the daily reconciliation effort substantially and accelerates the period-end close.

The reconciliation rules configured on each bank account define the matching logic the system applies when a bank statement is loaded. These rules evaluate characteristics of each statement line, such as payment reference numbers, amounts, dates, and transaction type codes, and attempt to find corresponding transactions in Workday’s payment and receipt records. When a match is found within the tolerance thresholds defined in the rule, the line is marked as reconciled automatically. Lines that do not match any rule, or that fall outside tolerance thresholds, remain as exceptions for manual review.

The effectiveness of automated reconciliation depends almost entirely on the quality of the payment reference data that flows from Workday into the payment file and then appears on the bank statement. If Workday generates payment reference numbers that are truncated or reformatted by the bank’s processing system before they appear on the statement, the reconciliation rules looking for those reference numbers will fail to match, and the exception rate will be higher than it should be. This is a configuration and testing issue that must be resolved by reviewing the actual bank statement format against the expected reference field values from Workday, and adjusting the reconciliation rule criteria accordingly. Discovering this mismatch only after go-live, when treasury is trying to reconcile a high-volume account at period end, is a common post-implementation challenge in Workday Financial Management environments.

For multi-currency bank accounts, reconciliation adds a further complication: the amount on the bank statement is in the account currency, while the recorded transaction in Workday may carry both a transaction currency amount and a company currency amount depending on how the original transaction was entered. Reconciliation rules must be configured to compare amounts in the correct currency dimension, and tolerance rules must account for the rounding differences that arise from currency conversion at different points in the transaction lifecycle.

Foreign Currency Revaluation: What the Process Does and Why Configuration Determines Accuracy

Workday’s foreign currency revaluation process serves a specific and well-defined accounting purpose. As described in Workday’s multi-currency accounting documentation, transactions in foreign currencies are recorded in the company currency at the spot rate on the day of the transaction. Financial assets and liabilities originally recorded at the spot rate are then revalued to the balance sheet rate at period end. The revaluation process generates the accounting journal that captures the difference between the spot rate used at transaction entry and the current rate at the period-end date, posting that difference to an unrealised gain or loss account.

The mechanics work as follows. A company with USD as its ledger currency enters a customer invoice for EUR 10,000 on 5 January when the EUR to USD rate is 1.10, recording USD 11,000 as the functional currency amount for the receivable. By 31 January, the rate has moved to 1.05. The receivable is now worth USD 10,500 at the current rate. The revaluation process calculates the USD 500 difference, recognises it as an unrealised loss, and posts a journal entry that reduces the receivable’s functional currency carrying value and credits the unrealised loss account. The transaction currency amount of EUR 10,000 does not change. Only the functional currency representation changes to reflect the current exchange rate.

Every transaction is evaluated for currency fluctuation between the transaction date and the period-end date during the revaluation run. For organisations with large volumes of open foreign currency receivables, payables, and cash accounts, a single revaluation run can generate hundreds or thousands of journal lines. This is expected behaviour. The volume of the output is proportional to the number of open transactions in foreign currencies at the period-end date, and it is the correct accounting treatment required by ASC 830 in the US and the equivalent provisions under IFRS for foreign currency monetary items.

Revaluation Rule Configuration: Reversal Settings, Account Assignments, and YTD vs. Activity Basis

The revaluation rule configuration is where the operational accounting decisions about how unrealised gains and losses are handled get encoded into the system. There are several configuration choices within the rule that have significant downstream effects on the general ledger and on the accuracy of period financial statements.

The first configuration decision is whether the revaluation entry is set to reverse automatically at the start of the following period. A reversing revaluation entry posts the unrealised gain or loss on the period-end date and then automatically reverses on the first day of the subsequent period. This approach, described in Workday’s own documentation and widely adopted by Workday customers, ensures that the unrealised gain or loss reflects only the exchange rate position at the specific period-end date and does not carry forward cumulatively into the next period. The alternative, a non-reversing entry, accumulates the exchange rate differences period over period, which is technically permissible under some accounting frameworks but makes reconciliation of the revaluation account considerably more complex.

The second decision is whether the revaluation is calculated on a year-to-date balance basis or on periodic activity. A YTD-based entry revalues the cumulative open balance in the account currency, calculating the unrealised gain or loss as the difference between the functional currency value of the full balance at the period-end rate and its functional currency value as previously recorded. An activity-based entry calculates the gain or loss only on transactions that originated during the period being revalued. The YTD approach is the most common configuration for balance sheet monetary items such as cash accounts, receivables, and payables, because it correctly restates the entire balance to the period-end rate, consistent with the requirements of ASC 830 and IAS 21.

The third decision is the account assignment for unrealised gains and losses. The revaluation rule must specify the general ledger accounts to which the unrealised gain and unrealised loss postings are made. These accounts must exist in the chart of accounts before the rule can be saved, and they must be distinct from the realised gain and loss accounts used when a foreign currency transaction is settled. Posting unrealised and realised exchange differences to the same accounts produces a balance in those accounts that cannot be meaningfully interpreted for financial reporting purposes, because it combines currency movements that represent completed economic events with movements that represent open positions that may reverse before settlement.

The revaluation rule is also where the scope of accounts subject to revaluation is defined. Not every account in the general ledger that carries foreign currency transactions needs to be revalued at period end. Balance sheet accounts holding monetary items, including bank accounts, receivables, payables, and certain accruals, require revaluation. Non-monetary balance sheet items such as fixed assets recorded at historical cost in a foreign currency do not require revaluation under most accounting frameworks, because they are carried at the exchange rate in effect on the original transaction date. Income statement accounts denominated in foreign currencies are typically translated using an average rate for the period rather than the period-end rate, and this is handled through the translation process rather than revaluation.

Currency Translation vs. Revaluation: Keeping the Processes Distinct

Translation and revaluation are two separate processes in Workday Financial Management that address different accounting requirements, and confusing them is one of the most persistent technical misunderstandings among finance teams new to the platform.

Revaluation, as described above, posts actual journal entries to the general ledger. It changes the functional currency carrying value of specific balance sheet accounts and generates a permanent audit trail in the ledger. Translation, by contrast, does not post to the ledger. It is a reporting-time calculation that converts the functional currency amounts already in the ledger into a reporting currency for the purpose of preparing consolidated financial statements. As confirmed by Workday’s own documentation, each time translated financial reports are run, Workday calculates the translated amounts dynamically based on the account translation rule set and the exchange rates in effect on the report date. No accounting entry is created.

The practical consequence of this distinction for period-end close is that revaluation must be run before translation-based consolidated reports are generated for the period. If revaluation has not been run, the functional currency amounts sitting in the foreign currency accounts reflect stale exchange rates. When the translation process then converts those stale functional currency amounts to the reporting currency, the consolidated financial statements are incorrect, not because the translation calculation is wrong, but because the inputs to the translation are not properly revalued. The dependency is linear: accurate exchange rate table as of period end, followed by revaluation run that updates functional currency balances, followed by translation-based consolidated reporting that converts those updated balances to the group reporting currency.

The multi-currency financial management whitepaper available on Workday’s resource library provides the framework for how organisations should structure this process, and practitioners configuring or troubleshooting a multi-currency Workday environment should treat the sequence of rate update, revaluation, and translation as a mandatory close checklist item rather than an optional post-close activity.

The Cash Management Web Service: API Architecture for Treasury Integration

Workday’s Cash Management Web Service exposes the banking and settlement data layer through a set of SOAP-based web service operations. For treasury teams integrating Workday with a treasury management system, a bank connectivity platform, or an automated bank fee analysis tool, these operations are the programmatic access point for bank account data, payment transfer records, and bank statement information.

The Get Bank Accounts operation retrieves bank account records with their full configuration data, including the bank account ID, financial institution details, routing and transit numbers, BIC and IBAN data, payment type assignments, reconciliation rule set references, and the full set of usage flags. The data returned by this operation is the system-of-record representation of each bank account and can be used by downstream systems to validate that their own account configurations are consistent with what Workday holds.

The Submit Bank Account Transfer for Settlement operation and the corresponding Get Bank Account Transfers for Settlement operation provide the API surface for programmatic initiation and retrieval of inter-account transfers that have gone through Workday’s settlement business process. These operations support treasury structures in which cash pooling or notional pooling arrangements require automated transfer instructions between legal entity bank accounts within the same Workday tenant, with the transfers being initiated by a treasury management system and submitted to Workday through the API for business process routing and accounting journal generation.

For organisations using the Power Automate connector for Workday or similar middleware platforms to automate finance workflows, the Cash Management web service provides the banking data that can be surfaced in treasury dashboards, automated cash positioning alerts, and bank fee reporting workflows without requiring manual data extraction from Workday’s reporting layer.

Real-Time Cash Positioning, Bank Fee Analysis, and Reporting

Workday’s banking and settlement module provides real-time visibility into cash balances across all configured bank accounts, a capability described in Workday’s financial management product documentation as real-time forecasting and visibility into cash balances. The cash position view draws from the combination of confirmed bank statement balances, pending settlement runs, and transactions that have been approved but not yet settled, giving treasury a forward-looking view of the cash available in each account as of any point in the settlement cycle.

For multi-currency environments, the cash positioning view must be evaluated with the current exchange rates in mind. A cash balance reported in Workday for a EUR-denominated bank account is expressed in EUR as the account currency. The functional currency equivalent of that balance at the current exchange rate is a derived calculation, and for treasury purposes this derived equivalent is the number that matters for managing the company’s overall liquidity position. When exchange rates are volatile, the functional currency value of a EUR cash balance can change materially between two settlement runs even without any actual cash movement, purely as a result of FX rate changes.

Workday also supports bank fee analysis through its delivered reports and queries for banking data, as described in the Global Country Configurations Catalog. Bank fees are recorded in Workday through ad hoc bank transactions that capture the fee amount, the fee type, and the bank account against which the fee is charged. These records can be analysed using Workday’s delivered reports to review global bank service fees, identify pricing variances across banking partners, and benchmark service fees against contracted terms. For organisations with complex banking structures involving multiple banking relationships across multiple countries, this fee analysis capability provides the visibility needed to optimise banking service pricing and identify accounts where fee structures have drifted from negotiated terms.

The reporting layer for cash management data in Workday is subject to the same security domain constraints as all other financial reporting, meaning that the cash position reports and bank statement reports available to a specific user are scoped to the bank accounts associated with the legal entities and organisations to which that user’s security groups are constrained. For treasury teams with global oversight responsibilities, the security configuration must explicitly grant cross-entity visibility to the relevant security groups, or global cash reports will return incomplete data without generating an error that explains why. This is a configuration consideration that connects directly to the data source permissions architecture governing what financial data each report consumer can access.

Intercompany Cash and Settlement: Configuration for Multi-Entity Environments

Workday’s settlement engine supports intercompany payments through the Used by Intercompany Payments flag on the bank account record. When this flag is set, the account can be selected as the source or destination for automated intercompany settlement runs that balance open intercompany receivables and payables between legal entities within the same Workday tenant. For organisations operating a shared services model or a treasury centre structure, this capability automates what would otherwise be a manual journal entry process at period end.

The intercompany settlement process in Workday interacts with the multi-currency accounting model in the same way as any other cross-currency payment. If Entity A has a EUR-denominated receivable from Entity B, and Entity B’s bank account is GBP-denominated, the settlement converts the GBP payment to EUR at the exchange rate in effect at settlement time and records both the EUR receipt in Entity A and the GBP payment from Entity B. The currency conversion gain or loss on the settlement, if any, is recorded as a realised exchange difference at the point of settlement, distinct from the unrealised differences recorded through the period-end revaluation process.

For organisations managing intercompany balances across entities subject to different accounting standards, such as one entity reporting under US GAAP and another reporting under IFRS, the account translation rule sets for each entity must be configured to apply the translation methods required by the applicable standard. The global-at-the-core design of Workday Financial Management supports the coexistence of multiple accounting standards within a single tenant through multibook accounting, allowing each entity to carry its own set of books with the accounting rules appropriate to its reporting framework.

Period-End Close Sequence and Operational Governance

The practical governance of multi-currency cash management and forex revaluation in a Workday environment requires a documented period-end close sequence that specifies the order of operations, the responsible parties for each step, and the validation checks that must be completed before moving to the next step. Without this sequence being explicit and consistently followed, the interactions between settlement timing, exchange rate loading, revaluation execution, bank statement reconciliation, and translation-based reporting produce results that are difficult to explain and harder to audit.

The sequence that most correctly aligns with the accounting requirements for multi-currency environments is as follows. The exchange rate table for the period-end date must be updated before any period-end revaluation is run, using rates sourced from the organisation’s designated rate provider. The revaluation run is then executed for all companies and revaluation rules in scope, generating the unrealised gain and loss journals for the period. Bank statements for the final days of the period must be loaded and reconciled before the period is closed, to ensure that the cash balances in Workday match the ending statement balances from the bank. Once these steps are complete, translation-based consolidated reports can be run with confidence that the ledger balances they translate have been properly revalued and reconciled.

This discipline connects directly to the broader post-go-live Workday deployment governance framework, where period-end close procedures are established as repeatable operational routines rather than ad hoc processes. For finance teams that inherited a Workday environment where the revaluation configuration was set up during implementation and has not been reviewed since, the starting point for improving cash management accuracy is a full review of the revaluation rules, the accepted currencies configuration on each bank account, the reconciliation rule sets, and the exchange rate loading frequency, against the current business requirements of the organisation.

Organisations that treat the Banking and Settlement functional area as a solved problem after go-live consistently find gaps at year-end or during external audits that trace back to configuration decisions made years earlier, when the business was smaller, the banking structure was simpler, or the multi-currency requirements were less demanding. The technical architecture that Workday provides for multi-currency cash management and forex revaluation is robust. The operational accuracy of the outputs depends on how precisely that architecture has been configured and how consistently the close process disciplines around it have been maintained.