The Settlement Details panel is a panel that is opened before the Settlement panel itself is activated. Using this panel, settings can be made that apply only to the specific transaction from time to time (such as entering a settlement amount) or settings that apply to all transactions under the contract (for instance, settlement definitions of the contract parties).

Reduction Amount

This panel is used to enter a customer discount by which the amount to be settled is to be reduced. The result of this calculation is displayed in the field “Red. (=Reduced) Settlement Amount”. This field is mostly used for settlement of a set of documents under an L/C or a collection. If the contracting parties agree to the documents being taken up against a discount being granted, the amount of such a discount negotiated will be entered in the statement as a customer reduction amount and thus reduces the document amount in question. In transactions that merely provide for the settlement of fees and therefore do not have a settlement amount, the field is deactivated and, therefore, no entries are possible. Whether the field Reduction Amount is activated or deactivated is defined via an entry in the transaction “Maintaining Entity Group Transaction Profiles” (DBxETP) or by means of a rule programmed accordingly in the source code.

Table “Settlement Definition of the Parties”

In this table, the following information can be defined for each party to a contract:

• their role
• the currency in which fees are to be settled
• the currency in which the contract is to be settled
• according to what disposition and to which account
• whether the settlement of fees is to be separated from settlement of the contract amount ('Separate Fees')
  Example: Settlement of a set of documents under an export L/C amounting to USD 4,000.00. On the Settlement Details panel, 'Fees separately' has been selected for the beneficiary. Settlement in relation to the beneficiary will be made as follows: Credit entry for USD 4,000.00, amount of fees charged under a separate debit entry.
• whether settlement is to be made via some other party

For all of these table entries, it is irrelevant whether the user already stores this information when the contract is created or at settlement time.

In account defaulting, a search for a direct account in the contract currency is first executed for each role. If no such account exists, the system will search for an account in the exchange rate base currency; if no such account exists either, a search is made for any other available account. Only if no direct account exists is the disposition PAx (Request for cover/debit authorization) proposed. The proposed values can be changed by the user.

Exception: If a reimbursement authorization was issued under an Import L/C, payment at the time of document settlement is made via the reimbursing bank, and the settings in the Settlement Details panel will be ignored (i.e., no automatic conversion will be carried out, even if the reimbursing bank has a direct account with the bank using the application).

In the field “Recalculate Rates on”, a date of execution can be entered for the service “Price/exch. rate revaluation” (PDX). If a date is entered, then the PDX service will be executed only once the specified date has been reached.

The currencies and accounts are taken into consideration in the course of each additional settlement under this contract.

In the bottom grid, the exchange rates are proposed with which settlement is be carried out for the relevant role.

The “Settlement” panel provides an overview of all information of relevance to settlement on the transaction selected.

Specifically, these are:

• The amount to be settled (if, for instance, this involves the settlement of a documentary amount, the [sight] amount to be settled is entered in this field)
• Settlement type (either final or temporary. A temporary settlement is provisional in nature, i.e. the application is used to generate an “invoice” that already contains all settlement information. This information is disclosed to all settlement parties in message format, but the actual posting to the accounts and the dispatch of a payment advice via SWIFT is only effected at the time of the final settlement). For further particulars on temporary settlements, please refer to the section Preliminary (temporary) settlements.
• Re-calculating exchange rates (if Service PDX is used and up-to-date prices/rates are not available as yet, in the case of final statements and conversions made, the automated exchange rate revaluation is activated)
• External fees
• Own fees
• Settlement amounts

Depending on the disposition code selected in Table 3, the payment messages required for outgoing payments are generated automatically.

The amounts which can be entered here can be debited to a cost centre outside the contract and credited to/transferred to a recipient. In this context, the bank acts as a correspondent for the two parties involved, who need to exist in the case of the transaction concerned.

Column	Description
1	Payer (person obliged to make payment) - determines who is to pay the amount
2	Beneficiary - defines to whom payment is to be made
3	Source - shows where the proposed fee comes from * P = Fee pool (a fee derived from the fee pool) * U = User (a fee manually entered by a user in this transaction) * D = Already advised (a fee that has already been advised and is newly derived from the pool)
4	Disp. - organizes the further handling of fees * X = settle now This selection is available for all final settlements, and the fees are displayed in the messages. * P = save in fee pool This selection ensures that the fees are only saved internally in the fee pool and are therefore settled at a later date. These fees are not shown in the messages. When a further transaction is started, these fees are derived from the pool and loaded in the settlement template. * V = Advice of fees These fees are also saved to the fee pool but are also displayed in the messages. * D = fees already advised Not allowed as an entry; displayed only if a fee already advised is newly loaded from the pool (Source = 'Already advised' (D)) so that the user is aware that these fees were already displayed in the messages relating to a preceding transaction. In this case, the fee row (apart from disposition) can no longer be modified; the fields in the Details Panel on the fee are also blocked to prevent user entries. Using the minus sign at the top right corner of the table, the fee already advised can be deleted in logical terms. The amount is then set to '0' and a warning is displayed for information to the user making the entry and the controller. * S = Preliminary (temporary) settlements This selection is only available if 'temporary' was selected as a settlement type; the fees are displayed in the messages, but no posting entry is made.
5	Text for payers - information on costs must be entered
6	Text for beneficiaries - information on payment must be entered
7	Currency - to be selected manually; the contract currency is the default option
8	Amount - to be entered manually or may be calculated
9	Icon - the amount payable can be calculated by clicking this icon. To this end, a settlement amount must be available and the start and end dates as well as the interest rate must be entered.

The middle section of the panel lists the bank's own fees in a table. Monitored by checkfields in each row, fees can be directly settled or entered in the fee pool for later settlements. Fees already in the fee pool from preceding transactions are proposed for settlement in subsequent transactions. If a fee placed in the pool is modified, then this modified fee will be saved along with the transaction.

Column	Description
1	Role - Cost centre for the fee. The designation of the role was abbreviated for lack of space and is visible as a three-digit role abbreviation. A mouseover of the role abbreviation for a moment displays the long text of the role abbreviation and the party belonging to the transaction are displayed in the form of a hint.
2	Code - fee code All fee codes available in this transaction are displayed. A mouseover on the fee code for a moment causes the long text of the fee to be displayed in the form of a hint. When opening the combobox, the relevant long text is displayed next to the codes. In the static data on fees (Transaction “[en:app:020cor:070ovs:020fee:0100dbifee]]”) it can be defined whether a fee is to be available only in a specified business sector, in a specfic transaction, or always.
3	(Fee) Source - shows the origin of the proposed fee * T = Transaction (a fee for settlement in this transaction proposed by the application by default. For the fees proposed in this manner, a fee entry is made in the transaction “Maintaining Transaction Configurations” (DBIATC) or there will be an appropriately programmed rule in the source. * P = Fee pool (a fee derived from the fee pool) * U = User (a fee manually entered by a user in this transaction) * D = Already advised (a fee that has already been advised and is newly derived from the pool)
4	Disp. - organizes the further handling of fees * X = settle now This selection is available for all final settlements, and the fees are displayed in the messages. * P = save in fee pool This selection ensures that the fees are only saved internally in the fee pool and are therefore settled at a later date. These fees are not shown in the messages. When a further transaction is started, these fees are derived from the pool and entered in the settlement template. * V = Advice of fees These fees are also saved to the fee pool but are also displayed in the messages. * D = fees already advised Not allowed as an entry; displayed only if a fee already advised is newly derived from the pool (Source = 'Already advised' (D)) so that the user is aware that these fees were already displayed in the messages relating to a preceding transaction. In this case, the fee row (apart from disposition) can no longer be modified; the fields in the Details Panel on the fee are also blocked to prevent user entries. Using the minus sign at the top right corner of the table, the fee already advised can be deleted in logical terms. The amount is then set to '0' and a warning is displayed for information to the user making the entry and the controller. * S = Preliminary (temporary) settlements This selection is only available if 'temporary' was selected as a settlement type; the fees are displayed in the messages, but no posting entry is made.
5	Units - displays the number of units charged. For instance, a unit may be a number of items or, in the case of an interest calculation, it can also be the number of interest days.
6	Long fee text - displays the fee text in line with the definition of fees in the static data (transaction 'Maintaining Fees'). The long fee text may be modified, depending on the definition in the static data.
7	Currency - the application defaults to the contract currency unless a different fee currency was stored for the role in question. A different fee currency can be entered for each party (role) existing in the contract on the Settlement Details panel
8	Amount - depending on the fee type (commissions, fixed fees), the amount payable is calculated or is to be entered. In the case of refunds, the amount must be preceded by a minus sign.
9	Icon - Clicking this icon displays the The 'Fee Details' Panel, and depending on the definition of the respective fee type, they can be modified.

The bottom section of the panel contains the sums of amounts to be settled for each party. The amounts listed result from the amounts in the first two tables, the settlement amount and, in the case of some transactions, also from entries made in other panels (such as cash cover posted). The calculation of the amounts is defined in the transaction. Moreover, the currency and type of payment are defined for the debit / credit entry.

Column	Description
1	Displays whether a settlement amount was split. If no splitting was carried out, then '-' is to be entered in this column. This is the default case. Further particulars in this regard can be found in the section Splitting of amounts.
2	Role - contains the code of the relevant party. The designation of the role was abbreviated for lack of space and is visible as a three-digit role abbreviation. A mouseover of the role abbreviation for a moment displays the long text of the role abbreviation and the party belonging to the transaction is displayed in the form of a hint.
3	in - currency for debit/credit entry (target currency)
4	Amount paid - contains the equivalent in the target currency, calculated at the exchange rate entered / stored. This is entered via the Details button or offered as a default by the application.
5	Disp - contains the disposition code for this row, with the letter 'D' at the end meaning a (debit) entry and the letter 'C' a (credit) entry. * DAD/ DAC - direct account, * PAD/ PAC - request for cover/debit authorization * IND/INC - (internal) booking entry to an interim account * HLD/ HLC - cash cover account (posted to an internal cash cover account for amounts in cash cover) * IBD/IBC - Processing Center Debit/Credit * BRF - BR pending payment * BEF - BE pending payment * TRF - Finance via trust receipt * HLD - Cash cover hold account * FND/FNC - Financing Debit/Repayment * TGC - Target Payment * IZD/IZC - IZV Debit/Credit * SIC - SIC/euroSIC Payment * SPD/SPC Sepa Debit Note/Credit Note * Other disposition codes, such as the disposition codes of the local clearing system, are possible - depending on the transaction and data constellation
6	Account - contains the suitable account suggested/selected for the disposition if a unique account number is available in the static data. Disposition and account depend of the so-called account defaulting. This defines what accounts and disposition types are suggested. If, for instance, a current account is found in the static data for the target currency selected, the disposition DAD/ DAC would be proposed. If there is no direct account but a nostro account in the target currency selected, the disposition PAD/ PAC would be suggested. If neither a loro nor a nostro account is stored for the target currency selected, the user can post entries to an internal account (IND/ INC).
7	Value date - the date of the day is suggested or the date fixed in the relevant currency/transaction. In the static data transaction “Maintaining Currencies” (DBICUR), it can be stipulated how many value dates are to be added to the date of the day on the debit and credit side.
8	D = debit, C = credit
9	Currency - the original currency is displayed here
10	Original amount - the original amount is displayed here before a conversion or currency translation was made.
11	Icon - Clicking this icon enables individual entries to be edited in this row. For further particulars, please refer to the section 'Settlement Booking Details'[[en:start Panel]].

For different payment types, additional panels can become active, in which the required information for Zahlungsnachrichten can be entered (e.g. parties to the payment).

When splitting occurs, the settlement amount is split up into different accounts, and possibly also in different currencies. In practice, it frequently occurs that a client would like settlement of the documentary amount to be debited to his currency account and the settlement of fees to be debited to his account in the system currency.
A splitting can be captured by the user entering the amount in the amount field that is to be debited/credited to the account entered there. If the user leaves the amount field with <Tab>, the application generates a further settlement line and enters the difference in amount in this row. The user can then carry out a conversion or post the entry manually to another account.
The fact that the amount is split is reflected by the application, with amounts depicted in blue and green. If a splitting is to be deleted, the user can delete the amount displayed in color, and only one settlement posting is generated again in the process.
Using the entry “Separate Fees”, splitting can be carried out automatically. For further particulars, please refer to the section Settlement Booking Details Panel.

There are situations in which the message 'inconsistent settlement' may be generated.

Example:

Under a contract, the person who assumes the fees arising from the transaction according to the contract is to be given a fee refund. In the 1st grid, the payer is captured as 'OWN', the beneficiary as the relevant role, dispo code 'X' and amount e.g. as 'EUR 3.00'. Next, in the 2nd grid the SWIFT fees appear as well as the panel “Payment 202”, only to disappear again. This occurs several times until the following message appears: 'Fee and settlement defaulting is inconsistent and has therefore been deactivated.' Via and , this action can be re-started over and over again.

What happens internally is this: The amount of EUR 3.00 is credited to the party; for payment purposes, a SWIFT message is generated, incurring the default SWIFT fee in the process, and this fee exceeds the amount of the credit note. As a result, the credit note is turned into a payment obligation settled by letter. As a result, the SWIFT message is done away with along with the SWIFT fee and the game begins all over again.

The correction can only be made by a manual correction of the basic data.
Variant a.) Collect the fee oneself and inform the party that it will not be passed on (or only passed on later) because the SWIFT costs exceed the revenue item in question.
Variant b.) Adding the SWIFT fee to the pool (to this end, initially setting the fee amount to an amount that exceeds the SWIFT fee. Clicking [Check] allows the settlement of all other data to be calculated, setting the SWIFT fee to 'Pool' and resetting the amount again.
Variant c.) Waive or reduce the SWIFT fee in such cases. To do so, proceed as under b.) and subsequently delete or adjust the amount.

In the field of import L/Cs or transfers, fees are sometimes settled in the settlement transaction vis-à-vis some other role than that originally advised. This is quite intentional, as the following example demonstrates:

An import L/C is advised; the fee rule provides for the fees to be assumed by the foreign side and deducted from the equivalent in value of the set of documents on settlement thereof. For this reason, when Opening an Import L/C (LITOPN), the fees to the advising bank ('ADV') are placed in the pool or advised accordingly (disposition 'P' or 'V').

If the presenter of the documents is also the advising bank, the fees advised/placed in the pool are deducted from the amount credited on settlement of the documents.

In many cases, however, the set of documents of the issuing or opening bank is not presented by the advising bank but by some other presenter ('PRB'). In this case, the user again wants to have the documentary value less the fees for the foreign party credited to the presenter on “Send, Accept and Settle Documents” (BRTPAY). As a rule, no fees are debited to the advising bank since the latter does not have anything more to do with the L/C once it has been advised, i.e. the fees originally assigned to the advising bank are now to be invoiced to the presenter.
To this end, it is stipulated in the Settlement module for the business sector that the 'ADV' fees are to be assigned to party 'PRB'. However, as the advising bank and the presenter are different parties, a warning message appears by way of an explanatory note to the user. If the user actually wants to settle fees in relation to the advising bank, this should occur in the main contract, i.e. in this case in the Import L/C section.

This panel displays details of the fees charged. These can be changed manually, irrespective of the definition of the fee.

The combobox at the top right shows what details of the fee have been modified manually. By selecting the entry 'unchanged/redefault', the original default status can be restored.

This panel shows details of the settlement which may be modified as required.

The exchange rates are shown in 3 rows, and the relevant currencies appear in front of the fields in question:

• the top rate - cross rate between the contract currency (original currency) and the currency used for posting
• middle rate - rate between the contract currency and the system currency
• bottom rate - rate between the system currency and the currency used for posting

By changing the rate type, the rates between the participating currencies can each be selected and/or entered.

Moreover, in the case of conversions, it can be seen which exchange rate was used along with the date of this rate. If rates were defined in the Settlement Details panel, a different rate can be entered manually by selecting the Checkbox “define own rates”.

The default exchange rate proposed by the application is determined in each case from the rate as at the value date or, where the value dates exceed the date of the day, from the rate last saved. Instead of the default exchange rate automatically proposed by the system, a free rate can be entered that will then serve as a settlement basis for conversion purposes.