Bank partner

The alert code in this field is used as the default. It is used in connection with electronic funds transfer.

This field is filled in when you enter a value in the Alert code field. The alert text in this field is used as the default.

The date is validated using the regional settings in Windows.

1 - Unibank (Denmark)

Obsolete format.

2 - DnB Telebank (Norway)

Obsolete format.

3 - Kreditkassen K-Link (Norway)

Obsolete format.

4 - Sparnett (Norway)

Obsolete format.

5 - Fokus Telebank (Norway)

Obsolete format.

90 - Visma Payment (BabelBank) - not in use

Obsolete format.

95 - Visma.net AutoPay

The recommended bank system today.

96 - Liinos

An internal format for finding Finnish customers only and has not yet been fully developed.

97 - Visma Services payment routine

An internal format for customers who want to use Visma Services’ own bank service.

98 - Visma AutoPay - not in use

The previous on premises version of AutoPay. Also known as AutoPay 3.

99 - Z Data Converter

Bank system provided by third party supplier of Visma.

This means you avoid having to change the account number in the Company information table when exporting. You can also enter the bank account number that is to be debited other places, and this applies in the following priority order:

1. Chargeable bank account no. from the Bank partner table.
2. Our payment acc. from the Payment line table.
3. Bank account for the currency line from the Currency table.
4. Bank account from Company information.
5. Postal giro from Company information.

This allows to set up several payment accounts without having to alter the table Company information, and you can select the various bank partners through generating suggestions.

Credit note due dates are also taken from the Bank partner table if the field is blank on the payment line.

Visma.net AutoPay is using this field to differentiate between different "Currency pockets" for payment formats for Nordea in Sweden.

It gets automatically filled when you select a value from the Std. EFT decl. code.

The authorities require the report of currency payments from the bank to contain a declaration code and a declaration text.

Payment suggestion

Estimated transfer date is payment date for all transactions

All transactions, regardless of the payment date, will be assigned the same payment date that you used in the Create payment suggestion processing.

Set extra text on payment post

You will be able to transfer text (40 characters) on an open post in the Additional text field. This has been implemented for the 96 - Liinos and 99 - Z Data Converter bank systems. Only Telepay (NO), Postal giro and Bankgiro (SE) can use this function.

No debit balance

Some EFT systems will test whether the payments per supplier exceed the total amount owed, and rejects this supplier and transactions that will create a debit balance for the supplier will not be paid.

Net credit notes towards invoices

Posting

Generate batch/vouchers for settlement from EFT system

Automatically create batch/vouchers when receiving settled payments from the EFT system. Recommendation is to have this setting selected. If not selected the Create account batch processing in the Payment line table can be ran manually at a later stage.

Automatically update batch for outgoing payments from Visma.net AutoPay

After return data for payments are received from Visma.net AutoPay, the Update batch processing will start automatically.

Update all settled payments in a single batch

When selected, one common batch with voucher lines is created for the settlements of outgoing payments received in the same status change report from Visma.net AutoPay. If this option is not selected, separate batches will be created for each <OriginalPaymentBatch> section in the status change report.

Incoming payments

Automatically update batch for incoming payments from Visma.net AutoPay

After incoming payments are received from Visma.net AutoPay, the Update batch processing will start automatically.

Use value date on Visma.net AutoPay incoming payments

When selected, the bank's "Value date" is used for the Value date field in the Voucher table, instead of the bank's "Booking date". With this the user can configure what suites best for optimizing their bank reconciliation.

Create voucher lines if charges from incoming payments from Visma.net AutoPay

When selected, charges will be posted when importing incoming payments from Visma.net AutoPay. Charges will be posted if they are specified in the <ChargesDeducted> tag in the import file. Alternatively, charges will posted if the value in the <PaidCurrencyAmount> is higher than amount in the <ReceivedAmount> tag (meaning the customer has paid more than we have received), the difference will be considered as charges (currency must be identical for both amounts).

Create bank posting for each incoming payment from Visma.net AutoPay

When selected, a separate bank voucher will be created for each incoming payment when importing from Visma.net AutoPay.

Ignore the group value when creating bank posting for incoming payments from Visma.net AutoPay

In the XML file for incoming payments from Visma.net AutoPay (VIP file) there is a tag named <Group>. Import of the incoming payments creates bank vouchers, with grouping based on payment date and <Group> values. When this setting is selected, the <Group> tag is not taken into account when creating bank vouchers.

Do not match CID payment when paid amount is larger than outstanding amount

Relevant for incoming payments which has a CID code, and where the paid amount is larger than open entry's outstanding amount (e.g. when the payer has used same CID code for payment of multiple invoices).

When this setting is selected, the Cross reference and Credit account fields will not be filled out on the voucher. The batch will then have a difference, making it easier for the user to see that something needs manual handling (e.g. matching of open entries).

Check for double payment by CID in customer transactions

When incoming payments are imported, but no match is found in the Open customer entry table, an activation of this parameter will result in an additional search for the CID code in the Customer transaction table. If the CID code is found; the customer no. is added to the voucher line and the batch will balance. In addition the text "Warning - double payment?" will be added to the Additional text field.

Do not check reminders in Customer document when matching payments

When selected, the content in Customer document tables will not be used for matching of incoming payments from Visma.net AutoPay.

Sweden

Accept negative payments

Negative amounts will also be processed. This check box is also present under Accounting processing field in the Company information table. By using this selection in the Bank partner table, you can set different processing for each bank partner.

Note:

For negative payments you are meant to transfer larger amounts of credit notes than invoices. This is selected when it is permitted to send this to the bank for monitoring, so that with the next invoice the bank reduces the payment amount with the remaining credit note value. This is only used when paying to Swedish banks.

Always use Post giro if exists

Post account is used in EFT processing. This applies for Sweden and is only used by some external EFT systems.

Numeric cost codes

The cost codes "OUR" and "BEN" will be replaced by numerical values that are used in Sweden.

Allow uploading payments with 0-amounts

When selected, the Create payment suggestion processing will create payment lines also for suppliers where the sum of the transactions is zero (e.g. one invoice with amount 2000 and one credit note with amount 2000). Check that your bank accept zero-payments, this is accepted by several banks in Sweden.

Denmark

Joint Transactions

Some EFT systems produces a joint transaction for the bank. If you use this parameter you cannot retrieve return data to match the payments. This field is only used in some external EFT systems.

Short message to receiver

The recipient receives a short message. This field is only used by some EFT systems.

Bank reconciliation

Update general ledger transactions with reconciliation amount

When selected, new transaction in the General ledger transaction table with Account no. = the bank partner's GL bank account will be assigned values in the Reconciliation rest amount fields. This makes it possible to later reconcile the transactions against the Account statement transaction table.

Match transactions even if amounts are different

Enables the possibility to match transactions with different amounts when running the Manual reconciliation processing.

Reconciling single transactions before multiple transactions

When selected, the 4 - Single transactions on same date reconciliation algorithm will be executed before the 2 - Multiple general ledger transactions on same date and 3 - Multiple account statement transactions on same date algorithms.

Reconcile using value date

Bank reconciliation based on principle Value date instead of Voucher date. When enabling Reconcile using value date, the algorithms will look into the value date instead of voucher date when executing the processes. Also, when running the bank reconciliation statement report, the value in the field Balance according to general ledger is calculated based on the value date for the transactions.

AutoInvoice

Do not send CID to AutoInvoice

When selected, no CID will be sent to AutoInvoice.

Miscellaneous

Use database connection for ZData

This field is not in use in this table.

Payments for active company only

You cannot export data from other clients than the client from whom the export was started.

Process active settling only for payments

You can only process the selected payment line for the company where Upload data or Download data was started from.

Update bank account/organisation no. from EFT system

You get updated bank account and organisation numbers of customers who are paying by OCR. Not all formats support this. It depends on the information in the file that comes from the bank.

Get currency exchange rate when creating payments

You will be able to get exchange rates from the bank, and update the Currency and Currency rate tables with updated exchange rates from the bank. Not all bank formats are supported at present.

Set to "Cancelled" for payments not transferred

Some EFT systems sets the Paym. line status field in the Payment line table to 4 - Cancelled in the lines that have status 1 - Estimate after you have run the Upload data processing in the Payment table. It is the EFT system that performs the cancellation of the open entries for everything that is rejected before you send data to the bank.

Set "Cancelled" on payments that are refused

Some external EFT systems will set the Paym. line status field in the Payment line table to 4 - Cancelled in the lines that are being cancelled by the control routines in the EFT system, while suggestions that you selected manually so that they will not be transferred remain as Paym. line status equal 1 - Estimate, and will be ready for paying the next time the EFT system is started.

Domestic payments to foreign countries (payment method 43/TBIO)

Foreign transactions will be sent over and processed as domestic transactions in the recipient country. This depends on what is offered by the bank that you use for the payments.

No exchange rate on processed payments

This field is not in use.

Accounting

Duty/Fees included in amount

Fees will be included in the total amount.

Fees per record

Fees and duties will be recorded per supplier and payment.

Do not post duty and fees

Fees and duties will not be posted with the payment. Select this field when you have a separate agreement with the bank that fees and duties are debited separately.

Taxes and fees in foreign currency

Fees and duties are in a currency other than default currency. Then the account currency is used for the fees.

Use bank reference, domestic

The bank reference will be used to gather the posting in the general ledger account for bank postings on domestic payments.

Use bank reference in foreign countries

The bank reference is used to gather posting in the general ledger account for bank postings in foreign payments.

Telepay

Only one invoice per transaction

Some EFT systems will only produces transactions for the bank. If you use this parameter, several payments will not be batched for the same account.

Payment suggestion

Estimated transfer date is payment date for all transactions

All transactions, regardless of the payment date, will be assigned the same payment date that you used in the Create payment suggestion processing.

Set extra text on payment post

You will be able to transfer text (40 characters) on an open post in the Additional text field. This has been implemented for the 96 - Liinos and 99 - Z Data Converter bank systems. Only Telepay (NO), Postal giro and Bankgiro (SE) can use this function.

No debit balance

Some EFT systems will test whether the payments per supplier exceed the total amount owed, and rejects this supplier and transactions that will create a debit balance for the supplier will not be paid.

Net credit notes towards invoices

Posting

Generate batch/vouchers for settlement from EFT system

Automatically create batch/vouchers when receiving settled payments from the EFT system. Recommendation is to have this setting selected. If not selected the Create account batch processing in the Payment line table can be ran manually at a later stage.

Automatically update batch for outgoing payments from Visma.net AutoPay

After return data for payments are received from Visma.net AutoPay, the Update batch processing will start automatically.

Update all settled payments in a single batch

When selected, one common batch with voucher lines is created for the settlements of outgoing payments received in the same status change report from Visma.net AutoPay. If this option is not selected, separate batches will be created for each <OriginalPaymentBatch> section in the status change report.

Incoming payments

Automatically update batch for incoming payments from Visma.net AutoPay

After incoming payments are received from Visma.net AutoPay, the Update batch processing will start automatically.

Use value date on Visma.net AutoPay incoming payments

When selected, the bank's "Value date" is used for the Value date field in the Voucher table, instead of the bank's "Booking date". With this the user can configure what suites best for optimizing their bank reconciliation.

Create voucher lines if charges from incoming payments from Visma.net AutoPay

When selected, charges will be posted when importing incoming payments from Visma.net AutoPay. Charges will be posted if they are specified in the <ChargesDeducted> tag in the import file. Alternatively, charges will posted if the value in the <PaidCurrencyAmount> is higher than amount in the <ReceivedAmount> tag (meaning the customer has paid more than we have received), the difference will be considered as charges (currency must be identical for both amounts).

Create bank posting for each incoming payment from Visma.net AutoPay

When selected, a separate bank voucher will be created for each incoming payment when importing from Visma.net AutoPay.

Ignore the group value when creating bank posting for incoming payments from Visma.net AutoPay

In the XML file for incoming payments from Visma.net AutoPay (VIP file) there is a tag named <Group>. Import of the incoming payments creates bank vouchers, with grouping based on payment date and <Group> values. When this setting is selected, the <Group> tag is not taken into account when creating bank vouchers.

Do not match CID payment when paid amount is larger than outstanding amount

Relevant for incoming payments which has a CID code, and where the paid amount is larger than open entry's outstanding amount (e.g. when the payer has used same CID code for payment of multiple invoices).

When this setting is selected, the Cross reference and Credit account fields will not be filled out on the voucher. The batch will then have a difference, making it easier for the user to see that something needs manual handling (e.g. matching of open entries).

Check for double payment by CID in customer transactions

When incoming payments are imported, but no match is found in the Open customer entry table, an activation of this parameter will result in an additional search for the CID code in the Customer transaction table. If the CID code is found; the customer no. is added to the voucher line and the batch will balance. In addition the text "Warning - double payment?" will be added to the Additional text field.

Do not check reminders in Customer document when matching payments

When selected, the content in Customer document tables will not be used for matching of incoming payments from Visma.net AutoPay.

Sweden

Accept negative payments

Negative amounts will also be processed. This check box is also present under Accounting processing field in the Company information table. By using this selection in the Bank partner table, you can set different processing for each bank partner.

Note:

For negative payments you are meant to transfer larger amounts of credit notes than invoices. This is selected when it is permitted to send this to the bank for monitoring, so that with the next invoice the bank reduces the payment amount with the remaining credit note value. This is only used when paying to Swedish banks.

Always use Post giro if exists

Post account is used in EFT processing. This applies for Sweden and is only used by some external EFT systems.

Numeric cost codes

The cost codes "OUR" and "BEN" will be replaced by numerical values that are used in Sweden.

Allow uploading payments with 0-amounts

When selected, the Create payment suggestion processing will create payment lines also for suppliers where the sum of the transactions is zero (e.g. one invoice with amount 2000 and one credit note with amount 2000). Check that your bank accept zero-payments, this is accepted by several banks in Sweden.

Denmark

Joint Transactions

Some EFT systems produces a joint transaction for the bank. If you use this parameter you cannot retrieve return data to match the payments. This field is only used in some external EFT systems.

Short message to receiver

The recipient receives a short message. This field is only used by some EFT systems.

Bank reconciliation

Update general ledger transactions with reconciliation amount

When selected, new transaction in the General ledger transaction table with Account no. = the bank partner's GL bank account will be assigned values in the Reconciliation rest amount fields. This makes it possible to later reconcile the transactions against the Account statement transaction table.

Match transactions even if amounts are different

Enables the possibility to match transactions with different amounts when running the Manual reconciliation processing.

Reconciling single transactions before multiple transactions

When selected, the 4 - Single transactions on same date reconciliation algorithm will be executed before the 2 - Multiple general ledger transactions on same date and 3 - Multiple account statement transactions on same date algorithms.

Reconcile using value date

Bank reconciliation based on principle Value date instead of Voucher date. When enabling Reconcile using value date, the algorithms will look into the value date instead of voucher date when executing the processes. Also, when running the bank reconciliation statement report, the value in the field Balance according to general ledger is calculated based on the value date for the transactions.

AutoInvoice

Do not send CID to AutoInvoice

When selected, no CID will be sent to AutoInvoice.

Miscellaneous

Use database connection for ZData

This field is not in use in this table.

Payments for active company only

You cannot export data from other clients than the client from whom the export was started.

Process active settling only for payments

You can only process the selected payment line for the company where Upload data or Download data was started from.

Update bank account/organisation no. from EFT system

You get updated bank account and organisation numbers of customers who are paying by OCR. Not all formats support this. It depends on the information in the file that comes from the bank.

Get currency exchange rate when creating payments

You will be able to get exchange rates from the bank, and update the Currency and Currency rate tables with updated exchange rates from the bank. Not all bank formats are supported at present.

Set to "Cancelled" for payments not transferred

Some EFT systems sets the Paym. line status field in the Payment line table to 4 - Cancelled in the lines that have status 1 - Estimate after you have run the Upload data processing in the Payment table. It is the EFT system that performs the cancellation of the open entries for everything that is rejected before you send data to the bank.

Set "Cancelled" on payments that are refused

Some external EFT systems will set the Paym. line status field in the Payment line table to 4 - Cancelled in the lines that are being cancelled by the control routines in the EFT system, while suggestions that you selected manually so that they will not be transferred remain as Paym. line status equal 1 - Estimate, and will be ready for paying the next time the EFT system is started.

Domestic payments to foreign countries (payment method 43/TBIO)

Foreign transactions will be sent over and processed as domestic transactions in the recipient country. This depends on what is offered by the bank that you use for the payments.

No exchange rate on processed payments

This field is not in use.

Accounting

Duty/Fees included in amount

Fees will be included in the total amount.

Fees per record

Fees and duties will be recorded per supplier and payment.

Do not post duty and fees

Fees and duties will not be posted with the payment. Select this field when you have a separate agreement with the bank that fees and duties are debited separately.

Taxes and fees in foreign currency

Fees and duties are in a currency other than default currency. Then the account currency is used for the fees.

Use bank reference, domestic

The bank reference will be used to gather the posting in the general ledger account for bank postings on domestic payments.

Use bank reference in foreign countries

The bank reference is used to gather posting in the general ledger account for bank postings in foreign payments.

Telepay

Only one invoice per transaction

Some EFT systems will only produces transactions for the bank. If you use this parameter, several payments will not be batched for the same account.

When generating a batch, GL account, bank fee is used as follows:

1. If you have filled in the GL account, bank fee field, the field in the Currency table will not be used.
2. If the Payment fee account field for the relevant currency is blank for other currency in the Currency table, the value for domestic currency will be used.
3. If you have not filled in the fields in points 1 and 2, the Posting errors account in the Company information table will be used.

When generating a batch, General ledger account bank is used as follows:

1. If you have filled in the GL account, bank fee field, the field in the Currency table will not be used.
2. If the Payments account field for the relevant currency is blank for other currency in the Currency table, the value for domestic currency will be used.
3. If you have not filled in the fields in points 1 and 2, the Posting errors account in the Company information table will be used.

The date is validated using the regional settings in Windows.

Number of days the transaction dates in the General ledger transaction and Account statement transaction tables can differ when executing the Automatic reconciliation processing.

The dates can differ e.g. when the payment date is set on a weekend/Holy day, but the transaction is not processed before the first working day.

Valid values are 0-7 (note that when no value is set, the standard value 1 day will apply). Larger values can give a better result with more matched transactions, but it can also increase the possibility for wrong matching (especially when having many identical amounts).

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

Organisational units fields can be used freely according to company needs to split accounting, sales and purchases into organisational units. The most common types are department, project and campaign. It is also possible to limit the organisational units a user should see by limiting the organisational units in the Limitation groups, User limitation groups and Limitations. The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

When a batch is created for a settled outgoing payment, this field is used to set organisation unit on the bank voucher. E.g. can different organisation units then be set for different bank accounts. If the field is blank, the organisational unit entered for the account in the General ledger account table will be used.

The field appear with the name assigned to it in the Company information table.

The fields are in use for Swedish payment paths.

The text code in this field is used as the default.