About Bank Statement Reconciliations

The Bank Statement form displays information relating to one customer or vendor bank identifier code (BIC) or to one employee account used for payment. Bank statement files are received in the proprietary format of specific banks. The files are transformed by an ION workflow that uses Infor Localization Services GEMS components with Infor standard BODs. The BODs are then sent by the workflow to SyteLine. For more information, see the SyteLine Integration Guide for Infor Localization Services.

Automatic A/P Payments

When a BankStatement BOD is received into SyteLine, automatic payments are generated for any A/P transactions in the statement that have a domain family code of Issued Direct Debits (IDDT) or Issued Credit Transfers (ICDT). Use the A/P button on the Bank Statement form to view the A/P payment transactions that were created automatically. The A/P button is enabled only for IDDT or ICDT transactions.

An agreement could exist between the provider and the customer for automatic transfer of funds as payment for a product or service. Control methods for this transfer of funds are considered separately; there is a general tolerance on the voucher and the payment that results in a variance that must be monitored.

Generally, you can expect that the bank statement is correct and can be reconciled with your general ledger. If the billing is incorrect and must be adjusted, perform the adjustment as a reversal, because it requires all parties to apply the adjustment. There is no reason to deny an automatic transaction that may be in error, because the other parties will still show an incorrect transaction until all parties agree on a resolution.

Note: This information about automatic payments does not apply if certain country packs (for example, Sweden) are enabled. See the appropriate SyteLine country guide for more information.

A/R and A/P Transactions in the Bank Statement

In order to balance your books, you must be able to view all relevant bank statement transactions (records and charges). Some records show transactions that require subsequent action; other records indicate a completed and accepted transaction:

A/R records usually require confirmation of an existing transaction that has already been initiated and performed.
A/P records usually require the execution of an A/P payment transaction. Ideally the payment is associated with a Vouchers Payable transaction and can be reconciled. The final reconciliation of the voucher must be done manually, because the process is variable. Not all A/P transactions require an A/P payment; for example, the transaction could be a result of a check, wire posting or other transaction type that is only being reported in the bank statement.

All bank statement line records are available for review. You must determine which records require manual action on your part.

Transaction Types

The bank statement can include many transaction types. The transaction type codes follow ISO standards, and are divided into domain codes, domain family codes, and domain sub family codes. For example, the Account Management (ACMT) family code is subdivided into domain family codes such as Miscellaneous Credit Operations (MCOP) and Miscellaneous Debit Operations (MDOP), which are further subdivided into domain sub family codes, for example Commission (COMM), Fees (FEES), Interest (INTR) and so on. These transaction codes are predefined on these forms:

ISO Bank Transaction Domain Codes
ISO Bank Transaction Domain Family Codes
ISO Bank Transaction Domain Sub Family Codes

Currency Exchange

The source currency for the bank transactions is always the account owner's currency. A/P transactions are converted to domestic currency using the specified exchange rate. Fluctuations in the exchange rate are reflected in the currency gains and losses. For more information, see About Realized and Unrealized Gains and Losses.

For example, a vendor bank account is established using the Philippine Peso (PHP). The bank statement reports all transactions using PHP. To apply an A/P voucher, the target currency for the voucher must also be PHP.

If a fixed exchange rate is applied (by agreement between all parties), no variance occurs due to currency fluctuations. If a variable exchange rate is used, all vouchers will have fluctuations based on currency rate fluctuations. Thus, to have the vendor's currency in balance with your domestic currency, there must be a redistribution if the exchange rate has changed since the voucher was created. This causes offsetting transactions for currency gains and losses, because the change in exchange rate changes the value of the PHP account in domestic currency. The voucher value would also be adjusted up or down in relation to domestic currency.

To protect against currency fluctuations, you can set up an account in the vendor's currency, and pay the vendor from that account. That way, the currency is never actually exchanged into your company's domestic currency, even though it is represented in SyteLine in the domestic currency amounts. Offsetting gains and losses cancel each other out.

If your payment account is in a different currency from the vendor's currency, then the exchange rate is determined at the time of payment, and you do not have offsetting currency adjustments. (If the payment is not in the vendor's currency or your domestic currency, no provision is made in the system for an exchange rate that requires manual translation.)

For A/R accounts in SyteLine, the currency used in the account must be either the domestic currency or the customer's currency. For A/P accounts, we recommend that you use either the vendor's currency or the domestic currency.