We always recommend mapping the amount field, and signing it (+/-) to signify whether the transaction is increasing or decreasing the cash account balance.


We avoid using the mapping fields Debits and Credit whenever possible - as the same transaction can have a different term depending on whether we are referring to the client's books or the bank's books.

Our model is centered on taking data from the client's perspective - and converting it into a BAI file that would support those transactions.  An example would be preparing a BAI file for consumption into SAP or Oracle's bank rec module.

For example, an amount signed with a negative sign, reduces the account and is a credit on the client's general ledger - and a debit on the bank's records.  The BAI File creation is bank-centric and uses a debit BAI code (our default 699).

The end result is a transaction that is considered a credit in the client's data, but is correctly associated with a debit BAI code.


Using Debits and Credits
Therefore, when you map the fields 'Debit' and 'Credit', you are indicating the client's data - and the BAI code in the BAI File will be from the Bank's perspective (the opposite).

What can you do:
--1. Simply reverse the Debit and Credit mapping fields to match the intended output.

What we are doing:
--2. We are looking into additional BAI named mapping fields to minimize this confusion (we understand the issue at hand). 
Please note that we will not be changing the handling or functionality of the Debit and Credit fields in #1.  #1.