Amc Banking 2012 5 For Dynamics Ax 2012 User Guide

USER GUIDE
AMC BANKING
FOR MICROSOFT DYNAMICS AX 2012
AMC Consult A/S

July 3, 2018
Banking 2012 v5
CONTENTS
1 Introduction...................................................................................................................................5
2 Facilities .........................................................................................................................................6
3 Prerequisites..................................................................................................................................7
4 Setup .............................................................................................................................................8
4.1 Parameters ............................................................................................................................8
4.1.1 Payments ................................................................................................................8
4.1.2 Posting ....................................................................................................................9
4.1.3 Web service ......................................................................................................... 11
4.1.4 Log ....................................................................................................................... 12
4.2 Banks .................................................................................................................................. 14
4.2.1 Advanced ............................................................................................................. 16
4.2.2 Bank holidays....................................................................................................... 17
4.2.3 Prices ................................................................................................................... 18
4.3 Own bank accounts ............................................................................................................ 19
4.3.1 Company setup.................................................................................................... 21
4.4 Customers and vendors...................................................................................................... 23
4.4.1 Bank accounts...................................................................................................... 25
4.5 Journals .............................................................................................................................. 28
4.6 Payment advice .................................................................................................................. 29
4.6.1 Advice types ........................................................................................................ 29
4.6.2 Preview ................................................................................................................ 32
4.7 Payment type priorities ...................................................................................................... 32
4.8 Search strings ..................................................................................................................... 34
4.8.1 Cleanup ................................................................................................................ 35
4.9 Transaction texts ................................................................................................................ 36
4.10 Workflows .......................................................................................................................... 37
4.11 Security roles ...................................................................................................................... 37
5 Payments .................................................................................................................................... 38
5.1 Prerequisites....................................................................................................................... 38
|Introduction 2
5.2 Payment journal ................................................................................................................. 38
5.2.1 Creation ............................................................................................................... 39
5.2.2 Preparation .......................................................................................................... 42
5.2.3 Validation ............................................................................................................ 44
5.2.4 Approval and transfer.......................................................................................... 45
5.2.5 Posting ................................................................................................................. 45
5.3 Email advice........................................................................................................................ 47
5.4 Additional functions ........................................................................................................... 48
6 Payment notifications ................................................................................................................ 50
6.1 Import................................................................................................................................. 50
6.2 Posting journal ................................................................................................................... 50
6.2.1 Auto match .......................................................................................................... 51
6.2.2 Manual settlement .............................................................................................. 52
6.2.3 Cash discount ...................................................................................................... 54
6.2.4 Additional functions ............................................................................................ 55
6.2.5 Posting ................................................................................................................. 56
7 Account statements ................................................................................................................... 57
7.1 Import................................................................................................................................. 57
7.2 Reconciliation ..................................................................................................................... 58
7.2.1 Automatic reconciliation ..................................................................................... 60
7.2.2 Manual reconciliation.......................................................................................... 62
7.2.3 Ledger proposal ................................................................................................... 62
7.3 Reports ............................................................................................................................... 65
7.3.1 Reconciliation report ........................................................................................... 65
7.3.2 Forecast report .................................................................................................... 66
8 Appendix .................................................................................................................................... 67
8.1 Aggressive credit note accumulation ................................................................................. 67
8.2 Charts ................................................................................................................................. 69
8.2.1 Troubleshooting .................................................................................................. 69
8.3 Posting scenarios ................................................................................................................ 70
|Introduction 3
8.4 Demo return file ................................................................................................................. 70
9 US Localizations .......................................................................................................................... 73
9.1 Positive pay journal ............................................................................................................ 73
9.1.1 Creation ............................................................................................................... 74
9.1.2 Transfer ............................................................................................................... 75
|Introduction 4
1 INTRODUCTION
To benefit as much as possible from your AMC-Banking module, you should read this user guide,
describing in detail, the various possibilities and functionalities offered by the module.
The user guide covers the basic setup of the module; meaning the setup that only needs to be done
once. Furthermore, it contains a detailed description of the module’s functionalities for you to
familiarize yourself with the daily use of the module.
Best regards
Development team
AMC-Consult A/S
|Introduction 5
2 FACILITIES
The Banking module covers three main areas of accounting.
Execution of payment
AMC Banking includes facilities for executing payment to all customers and vendors in the Dynamics
AX environment, and gives you access to hundreds of banks throughout the world.
For a complete list of banks, please visit:

http://amcbanking.com/support/amc-banking/microsoft-dynamics-ax/banks/
If your bank does not figure on the list of supported banks, please do not hesitate to contact either
your reseller or us, to find out the possibilities for adding your bank to the list.
Import and posting of payment notifications
AMC Banking includes facilities for importing and handling payment notification files, which contains
the physical credit and/or debit payments, which have been executed and posted on your bank
account(s).
Whether the payment notifications contain structured or unstructured payment information, the
module includes advanced functionality for identifying and settling the individual payments, allowing
the user to quickly handle and post the payment notifications.
Import and reconciliation of bank account statement
AMC Banking includes facilities for automatic account reconciliation based on electronic bank
account statements from the bank.
The reconciliation process matches the individual bank transaction against corresponding ledger
transactions. Furthermore, the account reconciliation functionality can quickly identify and post
bank transactions, which is unknown in Dynamics AX.
|Facilities 6
3 PREREQUISITES
To be able to complete the setup and actions described in this manual, there are several
prerequisites
✓ The latest version of the Banking module should be installed

✓ A valid Banking license should exist and the necessary license setup should have been
completed (
|Prerequisites 7
4 SETUP
4.1 PARAMETERS
Go to AMC Banking > Setup > Parameters.
4.1.1 PAYMENTS
The payments tab contains setup specifically related to the process of executing payment
The fields on the payments tab have the following features:
Field Description
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc
even though overdue
Centralized payment method The options are:
- Intercompany: Cross-company transactions are handled using standard AX
intercompany functionality, where transactions are posted both centrally and in
original company, using configured intercompany accounts.
- Partitioned: Cross-company transactions are handled centrally, but are posted in
their respective companies. Note, that using this option will typically result in the
creation of multiple posting journals, to keep transactions from different
companies separate.
|Setup 8
Party accumulation Enable, if payment proposal should attempt to accumulate invoices associated to same
party in global address book, when adding payments
Note: This option is only available, when using the Intercompany centralized payment
option, as it would directly conflict with the Partitioned way of doing centralized payments
Use standard payment methods If enabled, the module will pair individual invoices with certain own bank accounts if both
have identical payment methods.
Auto send If enabled, payment advices are automatically emailed to payees during transfer. If not
enabled, users must send the payment advices manually from the journal.
Note: The email is (only) send when the payment has been transferred successfully.
Note: Emails are send using standard AX email functionality. That also means that the
standard AX email setup is used to configure the SMTP relay server
4.1.2 POSTING
The posting tab contains setup specifically related to the process of posting payments
The fields on the posting tab have the following features:
Field Description
|Setup 9
Split payment notifications Specifies whether to split payment notification, so debit and credit transactions end up in
separate posting journals. This is useful in organizations where debit and credit transactions
are handled by different designated accountants
Name of (customer) journal The journal template to use for automatic created posting journals. If splitting of payment
notifications is enabled, this template is only applied to customer posting journals
Name of vendor journal The journal template to use for automatic created vendor posting journals
Auto match This mark specifies to automatically match payments that are created during import of bank
files
Medium match This mark specifies if the auto match functionality should be allowed to settle medium
matched open invoices, which as opposed to high matches are less evident
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc
even though overdue
|Setup 10
4.1.3 WEB SERVICE
The web service tab contains setup specifically related to the process of communicating with the
AMC-Banking web service
The fields on the web service tab have the following features:
Field Description
Solution The options are:
- Plus
- Enterprise
URL The URL of the web service which handles the conversion of payments and bank files. The
field’s background color will continuously be updated, reflecting the SSL certificate status of
the last web service connection.
- Green: Certificate is trusted and channel is secure
- Pink: Certificate is valid, but is not regarded as trusted, as it is not authorized by a
certificate authority (CA), typically because certificate is self-signed
- Red: Certificate is untrusted and channel is insecure. The Banking module will
block communication with untrusted web services
Note: The field is only editable on Enterprise solutions, where a designated web service is
hosted either locally or by a third party (Microsoft Azure or similar)
|Setup 11
Username The username/login used when communicating with the license server and the web service
specified in the URL field. Username is defined as the AX serial number.
Custom login If needed you can add a custom part to the AX serial number and use this for
communicating with the web service
Password The password used when communicating with the license server and the web service
specified in the URL field. Password is defined when creating your AMC-Banking license
Date verified The date the license was last verified
Note: The license is automatically verified every 14 days
4.1.4 LOG
The log tab contains setup specifically related to logging of the web service communication.
The fields on the log tab have the following features:
Field Description
Log detail level The level of information to retrieve and present when the Banking module communicates
with the web service and license server
The options are:
- All: Both regular info, warnings and errors
- Errors and warnings: Only warnings and errors
- Errors only: Only errors
|Setup 12
- Debug: All messages including “unstructured” messages (e.g. unhandled
exceptions)
Enabled Specifies whether logging of web service requests and response are enabled
File name The name of the web service log file residing on the server side
|Setup 13
4.2 BANKS
The general bank setup is set up from AMC Banking > Setup > Banks > Banks
When entering the setup form for the first time, the bank list is empty, meaning that no banks have
been made available.
To add banks, click Select banks. This will open a small form, in which banks can be added or
removed. To populate the Available (banks) list, click Update banks.
The module will now contact the web service specified in the parameter setup and request a list of
available banks and payment types. Once the bank update has finished, the individual banks can be
selected by using the arrow buttons.
Close the bank selection form and refresh the bank list to see the newly added banks.
To the right, a preview pane displays the payment types available to the individual banks and possibly
a brief description if further clarification on the payment type is needed.
|Setup 14
The fields on the fast tabs have the following features:
Field Description
Bank
Bank Identification of bank
Name Editable bank name/description
License bank Reference to a license bank, which is the web service’s own bank identifier. The license bank
is used by the module to instruct which bank format the web service should output when
creating payment files
Note: Usually this is a fixed value, which rarely needs changing
Requirements
Approval Display field, indicating, whether bank requires approval when executing payments
Login Display field, indicating, whether bank requires signing in, when importing bank return files
Payments
Calendar Reference to a holiday calendar, which contains the dates, where payments cannot be
executed by the banks
Note: If left blank, weekdays are considered payment dates and weekends are considered as
holidays.
Domestic payment currency Used to restrict domestic payments to a certain currency. If a currency code has been
specified, invoices in other currencies will be regarded as international transfers, when
executed using the bank.
Accumulate reference payments Used to specify, whether the bank allows accumulation of reference payments. If not
checked, reference payments executed from this bank will not be accumulated, resulting in
one reference payment per invoice.
Own reference Specify what to use for own reference, which is usually also shown on bank account and
related bank account statements
|Setup 15
4.2.1 ADVANCED
Clicking Advanced will open a form where additional bank setup can be configured.
Field Description
Company
Company Used to specify the scope of the advanced bank setup. The company field is used, if a
company specific bank setup is needed.
If left blank, the setup is considered a general setup, which will be used in all companies,
which do not have company specific setups
Name The name of the advanced bank setup.
Payments
File to bank Used to specify where to save created payment files
Import
Disable Used to disable and thereby skip the import of files, using these settings
Path from bank The path where bank files are stored prior to import
Archive The path where bank files are archived once successfully imported
Bank agreement
Bank agreement 1 Used to identify a bank agreement (if any)
Bank agreement 2 Used to identify a “sub-level” bank agreement (if any)
Alternative sender
Alternative sender Used to override the default sender name, which is otherwise fetched from standard AX
company setup
|Setup 16
4.2.2 BANK HOLIDAYS
Bank holidays are set up from AMC Banking > Setup > Banks > Bank holidays
Depending on the country of the bank and sometimes even the payment format, a given bank has
certain dates where payments cannot be executed (cleared). The bank holiday setup is used to set
up non-payment dates, and is used to ensure that payments are created on dates where they can be
executed.
Besides the obvious benefit of getting one’s payments executed, this also helps getting the most
accurate result, in relation to dates, exchange rates etc., when posting payments.
You can set up several bank holidays calendars, which can be specified on the various installed banks
that do not adhere to the same calendar (see 4.2).
Field Description
Calendar Identification of the bank holiday calendar
Description Brief description of the bank holiday calendar
Ignore weekend Used to specify whether to allow payment on weekends. If checked weekends are
considered as regular weekdays and thereby payment days.
Maintain list of bank holidays In this section, you can setup the bank holidays for this calendar
|Setup 17
4.2.3 PRICES
The price setup can be opened either by clicking the Prices button, which will open only prices related
to the selected bank, or from AMC Banking > Setup > Banks > Prices
The price setup is used to configure the costs related to executing payments of a certain payment
type.
When requesting a list of available banks and related payment types (see 4.2), the web service will
also return an estimated price for executing each payment type. If the prices are inaccurate, e.g. if
your company have negotiated favorable prices, both the price and the related currency can be easily
corrected in this form.
|Setup 18
4.3 OWN BANK ACCOUNTS
The setup related to your company’s own bank accounts is opened from AMC Banking > Common >
Own bank accounts.
Like most list pages, the menu contains several buttons covering the general maintenance of the
bank accounts. Furthermore, the menu contains buttons for account reconciliation (see section 7)
and for balance chart, cost chart and post chart (see section 8.2)
Clicking either New > Bank Account or Maintain > Edit, will open a separate, detailed bank account
setup form.
|Setup 19
Field Description
Bank
Bank The internal bank to which the bank account belongs
Bank account The account number that is assigned by the bank
Note: Both local bank account numbers (BBAN) and IBAN numbers are allowed in this field
Currency The currency of the bank account
SWIFT code The SWIFT code identifying the bank and possibly branch
General
Company The company or legal entity in AX to which the bank account belongs
Restrict to company Restrict the bank account to the company where it resides (specified in the Company field),
and thereby prevent the bank account from being used in other companies. This field is not
to be confused with the general company setup’s Payment field, which specified which
companies’ invoices can be paid.
This option is typically used by holding companies with subsidiary companies, as it allows
the holding company to create payments based on the subsidiary invoices, while restricting
the bank account from being used by the subsidiary companies.
|Setup 20
Priority The priority of the bank account used to specify how bank accounts are prioritized against
each other. The lower the number, the better priority. However, the priority is only used, if
no other match is found based on currency, method of payment etc.
More currencies Specifies whether to allow other currencies than the bank account’s own currency
Bank groups Used to group bank accounts together. The bank groups are used by the balance form parts,
which calculates and displays the total balance of both individual bank accounts as well as
bank account groups
Offset account type Used to specify the type of the offset account in AX.
The options are:
- Bank
- Ledger
Offset account Used to specify the offset account in AX which the bank account correlates to
Customer payment method Used to link the bank account to a certain standard AX customer payment method.
When adding payments, the module will attempt to pair open customer invoices with bank
accounts with similar payment methods.
Note: This field is only visible and used if standard payment methods are enabled in
parameter setup
Vendor payment method Used to link the bank account to a certain standard AX vendor payment method.
When adding payments, the module will attempt to pair open vendor invoices with bank
accounts with similar payment methods.
Note: This field is only visible and used if standard payment methods are enabled in
parameter setup
Bridging posting If a selected method of payment is setup to use bridge posting, you have activated the
bridging functionality, and this field is automatically marked. This means that posting of a
payment journal will use the bridging account as offset account instead of the bank account.
Fee collection Specify whether fees are being collected on bank account and thereby whether to ignore
transaction related (sub)fees or not.
Note: Individual fee transactions will still be imported

Auto match class Field used to specify, which auto match class to use for auto matching imported transaction
related to the bank account.
If left blank, the auto match functionality will use the default auto match class, which is
distributed as part of the AMC-Banking module
Reconciliation
Start date The date on which to start reconciling
This date is typically used when the reconciliation functionality is started later than the AX
implementation, where existing ledger transaction is either reconciled already or old
electronic account statements is not available.
The start date indicates the date on which transactions are included in the reconciliation
process. Therefore, ledger transactions posted prior to the start date, will not be included in
the reconciliation functionality, e.g. in the reconciliation form and report
Bank balance Used to specify the bank account’s balance on the start date. The balance is used in the
reconciliation report
Ledger balance Used to specify the ledger account’s balance on the start date. This field is only visible when
offset account type = bank. The field is typically used in cases where ledger opening
transactions does not have the necessary data, linking them to the bank account specified as
offset account. In those cases, the report is not able to retrieve the opening balance
automatically.
4.3.1 COMPANY SETUP
|Setup 21
The company setup tab is used to set up, how the individual AX companies and/or legal entities can
utilize the bank account.
The default is that the company, in which the bank account resides, is allowed full access to the bank
account, while all other companies are restricted from using the bank account at all. If a bank account
is shared across AX companies or legal entities, companies can be added to the company list.
Note: To permit users from seeing bank accounts, which are not relevant to them, bank accounts are only
visible in companies, that are included in the company setup. Furthermore, the company setup is only
available in the bank account’s own company. This ensures that bank account visibility and company setup,
can only be changed by users with the required access to the company of the bank account.
The fields in the grid have the following features:
Field Description
Company Identification of the company in AX
Payments Specifies whether payment journals in the related company can use the bank account
Posting The company in which to add the posting journals created because of importing bank files,
e.g. customer- and vendor payments
Note: Only one company can be the posting company
Auto match Specifies in which companies to look for open invoices when the auto match functionality is
executed
|Setup 22
4.4 CUSTOMERS AND VENDORS
Setting up payee bank information is done from either AMC Banking > Common > Customers or
AMC Banking > Common > Vendors, which opens list pages providing a quick payee overview.
Note: The customer and vendor setup forms are almost identical in relation to both design and
functionality. Having two setup forms, primarily serves to keep customers and vendors separate. The
following section will therefore in certain cases only cover the vendor setup form, which is the most
commonly used in relation to payments
Unlike earlier versions of Banking, the current version utilizes standard AX’s customer/vendor bank
accounts, which helps reduce redundancy. Thus, all customers and vendors with related bank
accounts are considered payable, usually without the need for additional setup. Therefore, the
customer and vendor setup forms are only used, in cases where customers or vendors are to be
excluded from the payment process or in those cases where additional information is required.
|Setup 23
The left-most status icon field in the grid have the following features:
Field Description
Status An image displaying the payment status of the vendor.
The options are:
- [Green check mark]: The vendor is enabled and has related bank account setup,
hence is considered payable. The vendor’s open transactions are included in
payment process
- [None]: The vendor is enabled, but has no bank related setup. The vendor’s open
transactions are included in payment process
- [Red cross]: The vendor has been disabled, hence the vendor’s open transactions
are excluded from the payment process
Clicking the Edit button will open a detailed vendor setup form
|Setup 24
The fields in the form have the following features:
Field Description
General
Account type Specifies whether it is a customer or a vendor account
Account number The account number of the vendor
Name The name of the vendor
Disabled Specifies whether the vendor has been disabled and should be excluded from the payment
process
Discount
Grace period The number of days to allow overdue cash discount
Payment accumulation
Override Used if default payment accumulation of open invoices should be overridden on specific
vendor level
Payment accumulation Specifies how open invoices should be accumulated when creating payments. See section
4.1.1 for more information
Advice
Disable auto advice Used to prevent automatic building of payment advice based on the invoices included in the
separate payments. Disabling the auto advice enables the advice field, which allows the user
to choose an alternative advice
Advice Reference to the advice template, which is used to create the electronic advice included in
the payment file
Note: If nothing is specified, an automatic advice is created
Email advice
E-mail Email address to use when sending payment advices to vendor
E-mail ID AX email template to use when sending payment advices to vendor
Report design name Advice report design to use for payment advices
File format File type of the advice report file being attached in the advice email
4.4.1 BANK ACCOUNTS

Customer and vendor bank accounts can be maintained either directly on the detailed
customer/vendor setup form or by clicking the Payment > Bank accounts button in the list page
menu.
|Setup 25
The fields in the form have the following features:
Field Description
Identification
Bank Bank account identification
Name Name of the bank account
Bank account
Routing number type Code identifying the type of the routing number
Routing number Routing number of the bank
Bank account number The account number that is assigned by the bank
SWIFT code The SWIFT code identifying the bank and possibly branch
Currency Currency code of the bank account
Note: Specifying a currency code will result in the bank account being restricted to
transactions of that currency only.
Correspondent bank account Used to specify a bank account to use as correspondent bank account. This is a reference to
another of the payee’s bank accounts and correspondent bank account cannot be the same
bank account, as the current selected bank account
Payment type
Payment type Used to tie up the bank account to a specific payment type. Thus, the specified payment
type will be used on all future payments to the bank account
Note: If a payment type is not specified, the payment creation functionality will attempt to
find the most appropriate payment type based on the individual open invoices (see section
0)
|Setup 26
Address
Bank address The address of the bank related to the bank account
Alternative address Used to specify an alternative vendor address. If nothing is specified, vendors primary
address is used
Bank rules
Customer ID Receiver’s identification of payer. This
Costs Used to specify how to allocate payment related costs.
The options are:
- Shared: Charges are split between sender and receiver of the payment. Usually
payer will be charged a fee for creating the payment order, whilst the receiver
will be charged for costs related to intermediary banks and sometimes also a fee
for receiving of the money.
- Payer: All fees are charged to the sender of the payment
- Payee: All fees are charged to the receiver of the payment
|Setup 27
4.5 JOURNALS
The general behavior of the posting journal is set up from AMC Banking > Setup > Journals >
Journals.
Field Description
Voucher
New voucher Specifies how and when new vouchers are fetched. The options are:
- In connection with balance
- Manual
- One voucher number only
Voucher series The voucher series used
Financial dimensions
Default financial dimensions The journal can be configured with financial dimensions, which will automatically be added
to created journals
|Setup 28
4.6 PAYMENT ADVICE
Electronic advices for payment files are set up from AMC Banking > Setup > Payment advices.
When executing payments, it is important to create a satisfactory message to the recipient. AMC-
Banking contains several options for creating electronic advices, and it is possible to design an
unlimited number of templates for advices sent to the recipients.
4.6.1 ADVICE TYPES

It is possible to create three types of advices:
- Compressed: Comma separated invoice numbers

- Dynamic: Custom configurable advice with a limited number of fixed placeholders
- Class: Fully customizable advice class
It is not a requirement to set up advices. If no advice setup is found, an advice suitable for the payment
file will automatically be created by the web service based on the individual open invoices
4.6.1.1 C OMPRESSED
A compressed advice is a list of invoice numbers separated by commas, and it is typically used to
conserve space in formats with very limited space for advice. The only configurable part is a header,
which is used to prefix the invoice list.
This setup will create an advice like this:
“Invoices: 123456789, 321654987, 4654231….”
|Setup 29
4.6.1.2 DYNAMIC
Unlike the compressed advice, the dynamic advice is highly customizable and has several properties,
which can be tweaked to suit your specific needs. The dynamic advice is typically used, where advice
possibilities are rich, and only the most common invoice data, like invoice no., date, amount etc., is
to be included
The dynamic advice consists of three different text sections, each separated by new line:
Header: A one-time occurring header being output at the start of the advice. The text can contain
several lines of text, but should not exceed the maximum length of the payment file’s advice.
Most payment file formats allow 35 characters of text per line.
|Setup 30
1) Body: The body is being output once per open invoice settled on the individual payment.
The body can be outputted in a single line or in one line per invoice by enabling the
Linefeed field
The body allows several placeholders, which represent various data related to the
individual open invoice:
➢ %1: Invoice no, left justified
➢ %2: Invoice amount, right justified
➢ %3: Invoice currency, left justified
➢ %4: Invoice date, left justified
➢ %5: Utilized cash discount amount, right justified
➢ %6: Customer/vendor account number, left justified
➢ %7: Transaction text, left justified
Each placeholder is “paired” with a related length property, which helps keep diverse
invoice data aligned. It is important to fill the length, if a placeholder is used. Otherwise, you
will not see a value in the advice
2) Footer: A one-time occurring footer being output at the end of the advice. Like the header,
the footer can contain several lines of text, but should not exceed the maximum length of
the payment file’s advice.
|Setup 31
4.6.1.3 C LASS
The class option offers building advices using a fully customizable class, and is typically used in cases,
where the invoice data covered by the placeholders, just do not cut it. E.g., the class could be used
to fetch related data from the any AX module.
The only configurable part is the Class name field, which is used to specify the name of the advice
class to use.
A class is only considered a valid advice class, if the class extends AmcBankAdviceClass, whic h forces the
advice class to implement certain functionality.
4.6.2 PREVIEW
Regardless of the payment advice type, it is possible to generate an advice preview by clicking
Preview. This allows the user to test the advice setup continuously during set up.
The preview is generated from the selected advice setup using a random payment transaction. Therefore,
the preview functionality will return an error if no payment transactions exist
4.7 PAYMENT TYPE PRIORITIES

|Setup 32
When adding payments, users are presented with several payment proposals, representing different
payment scenarios. Should the users find the default provided payment proposals inadequate, they
can instead setup their own prioritized list of payment types from AMC Banking > Setup > Payment
type priorities.
On the left side, the priority form contains an overview of existing payment type priority lists. On the
right side, the form contains a list of prioritized payment types related to the current selected priority
list. To manually prioritize payment types across banks, edit the payment type list.
Once a priority list has been created, it will automatically be included in future payment proposals.
If the User only check box is checked, the payment proposal will only be included in payment
proposals initiated by the Created by user.
|Setup 33
4.8 SEARCH STRINGS
As a feature, it is possible to add rules that tie certain text and/or codes on bank payments to a given
action or account in AX. The search string setup is very useful and allows the user to adjust the default
provided auto match functionality easily.
The search string setup is opened from AMC Banking > Setup > Search strings.
The setup form contains a list containing various combinations of search strings, transaction codes
and their related action and/or account.
It is also possible to open the search string setup from either the customer or the vendor form. In that case,
the list only includes search strings related to the selected customer or vendor.
The Search string field is used to match a user-defined text. This is e.g. useful in situations where a
registered customer name in the AX does not correspond with the name provided by the customer
itself or the bank, when a payment from the customer is received. In such cases, the user can easily
add the provided customer name, which will allow the auto match functionality to determine the
customer based on the provided search string.
The Transaction code field is used to match transaction codes originating from the bank. Most banks
“tag” the individual bank transaction with transactions codes (also known as business transaction
codes), which helps determine the nature of the transactions. This is particularly useful, when
receiving recurring, known, yet unexpected financial transactions like fees, interests etc. In such
cases a transaction code can easily be tied to the related AX ledger account, allowing the auto match
|Setup 34
to quickly identify and prepare the transaction, which can then be posted with minimal user
involvement.
The search strings and transaction codes can be tied to three different actions:
- Match:
Used to tie a text string and/or transaction code to an account in AX. When met, the auto
match functionality, will apply the set-up account to the transaction.
- Delete:
Used to delete transactions. When met, the auto match functionality will delete the
transaction and inform the user, that a transaction was deleted.
- Bridge post:
Used to initiate bridge posting of the transaction. When met, the auto match functionality
will apply the related bank account’s bridge account to the transaction. This is particularly
useful, when using account statements to post bulk payment, which have been specified in
earlier files. E.g. Lockbox files (US) and FIK-indbetalinger (DK)
4.8.1 CLEANUP
Each search string record has two related date fields, specifying when the individual search string
was created and last used. The two date fields are useful when cleaning up search strings, as it
provides a quick overview of, which search string rules are being used regularly.
To help keep the search string list neat and tidy, the search string setup includes cleanup
functionality, which is activated by clicking Cleanup in the top menu. The button opens a simple
dialog, in which the user can specify Older than number of days.
Upon clicking OK, the cleanup functionality will delete all search string records, which have not been
used the specified number of days. The cleanup functionality is batch executable, allowing the
cleanup job to run continuously in the background.
|Setup 35
4.9 TRANSACTION TEXTS
The transaction text setup, which is reflected on the individual journal transactions’ Description
fields, is set up from AMC Banking > Setup > Transaction texts
The transactions text setup form is used to set up account type specific transaction text. E.g., it is
possible to use different transaction text on vendor and ledger transactions.
Furthermore, it is possible to create language specific transactions texts. E.g., it is possible to

configure both a Danish and English vendor transaction text. This will result in the description on
transactions related to a Danish vendor being built from the Danish transaction text setup and the
description on English vendor transaction being built from the English transaction text setup.
If the language field is left blank, the transaction text is used on transactions that does not relate to
a configured language. Using the previous example, a French vendor’s transaction would neither
fetch the description from the Danish or English setup, but instead fetch the description from the
default vendor configuration without language specified.
|Setup 36
4.10 WORKFLOWS
To ensure that payments are only executed if the related customer/vendor bank accounts have been
approved, the Banking module includes a workflow. For more info, please see the separate Activate
bank account approval workflow document.
4.11 SECURITY ROLES

To access the Banking module, users must be assigned with the proper security roles. For more info
on Banking security role assignment, please see separate Set up security roles document
|Setup 37
5 PAYMENTS
This section covers the creation, approval and execution of payments.
5.1 PREREQUISITES
Customer and vendor transactions are created and posted from several locations, e.g. via the invoice
register journal, the invoice journal or the ledger journal. To be picked up and processed by the
Banking module, they are however all subject to a few common requirements:
✓ Must be approved
✓ Is not settled elsewhere
✓ Is in the selection range, defined in the payment add dialog
5.2 PAYMENT JOURNAL

The payment journal is used to create and process payments based on open customer and/or vendor
transactions and can be opened from AMC Banking > Journals > Payment journal.
From the payment journal menu, the user is offered options like creating new payments as well as
viewing, editing and processing existing payment. To see the details of the individual payment
journals, select a journal and click Lines.
|Payments 38
The payment journal form contains the following fields:
Section Meaning
Company The company indicates the id of the company, where the payments are processed from
Bank The bank set up under Setup > Banks > Banks, which is used to execute the payment batch/journal
Journal The id of the journal, which also works as a payment batch’s unique indicator.
Unlike most other journals, the journal id of the payment journal is not based on number sequences or
voucher series. The journal id is instead constructed from the payment company combined with a shared
counter, which ensures that payment journals across companies can be processed without violating bank
uniqueness constraints.
Description Description of the journal
Lines Shows the total number of payment lines in the journal
Errors Shows the number of erroneous payment lines in the journal
Posted Shows the number of posted payment lines in the journal
5.2.1 CREATION
Thought the module allows the processing of payments to customers, the most common scenario is
that payments are created and processed from open vendor transaction. Processing of customer and
vendor payments are two identical processes, so despite the following section primarily focusing on
vendor payment scenarios, the section should also be sufficient to process customer payments.
To create payments, click either Add > Customer payments or Add > Vendor payments button.
Doing so, will open the Add payments dialog.
|Payments 39
The dialog contains of two sections, where the left side is used to present payment proposals based
on the configurations specified by the user on the dialog’s right side.
The user is presented with fields, which allows the user to quickly limit the included transactions as
well as affecting the payment creation behavior.
Section Meaning
Pay to date If the search is only to be based on regular due conditions, a date may be entered in this section and
used as limitation in the search. Invoices due until and including this date are included in the search.
Add cash discount If your company uses cash discounts, this field can be used to also include invoices, which is not
necessarily due yet, but on which cash discount can be achieved within Pay to date. Invoices, that are
cash discount eligible between the current date and the specified discount date are included in the
search
Forced payment date Used to override the automatic payment date determination and instead use a forced payment date,
disregarding holiday setup etc.
Payment accumulation The options are:
- Due date: Invoices and credit notes are accumulated per due date
- Period (First): Invoices and credit notes are accumulated in total, and payment date is the
due date of the first invoice in the selection
- Period (Last): Invoices and credit notes are accumulated in total, and payment date is the
due date of the last invoice in the selection
None: Invoices and credit notes are paid separately
Credit note accumulation Method used to accumulate credit notes during creation of vendor payments. The options are:
- Passive: The Banking module respects credit notes’ due date, which will only be
accumulated with payments with same due date.
- Aggressive: Future credit notes are included even though outside the specified date range
and due date is overridden. See section 8.1
In addition to the fields, which have been placed directly on the dialog, the user can further limit the
transactions, by adding user defines ranges, using the Select button.
To activate cross company payments, use the Select button to change the company included. This is done
from the designated tab Company range
Once the desired ranges have been specified, the Refresh button, placed right next to the payment
proposal grid, is used to generate the payment proposals.
During the payments proposals generation, the module will automatically attempt to determine
bank accounts, payment types and other information related to the individual payments. This is
determined by several criteria, e.g. the available and active banks configured in the bank setup. For
an overview on how payment information is determined, see separate Determine payment
instruction document
Each payment proposal includes the exact same invoices, but represents different ways of
processing, the found, open vendor transaction and thereby the final payments. The individual
payments will usually differ based on the executing bank(s), e.g. by having different payment types,
different accumulation principles etc.
|Payments 40
It is possible to process payments using only a single execution bank, but it is also possible to process
payments using multiple execution banks, e.g. to process payments the cheapest way possible.
Next to the payment proposal grid, it is possible to get a quick overview of the payment types
included in the individual proposals. Furthermore, the Payment transactions tab can be used to see
the individual transactions, included in the payment proposal, in details. E.g. it is possible to see the
bank accounts involved and the estimated price for executing the individual payments.
It is possible to change the included transactions, as well as the payment behavior, dynamically, by
modifying the dialog fields or the user specified ranges. Doing so will result in the Create button
being disabled and the Refresh being re-enabled. This ensures that the user must click the Refresh
button, thereby regenerating the payment proposals based on the latest defined ranges, behavior
etc.
Above the Refresh button is two additional buttons, which is used to run checks, which can be
executed repeatedly on the individual payment proposals:
✓ Check balance: Used to check the balance of the payee, customer or vendor, and investigate
whether the total sum of payments for the payee exceeds what the payee is owed, e.g. due
to future credit notes. If the payee balance is exceeded, the check returns a warning,
If this check is used frequently, consider whether to use aggressive credit note accumulation
✓ Check ledger: Checks whether the involved bank accounts have sufficient balance to process
the payment, without resulting in a negative balance.
The balance is calculated using the bank account’s offset account balance, and if the balance
is being exceeded, the check returns a warning,
|Payments 41
To finish the payment proposal process and create the payments, select the desired payment
proposal and click the Create button. This will result in one or more payment journals (one journal
per execution bank) being created.
Payments can also be added from inside the individual payment journals, which has similar menu buttons
for initiating payment adding. When adding payments from inside a journal, the user will only be presented
with a single payment proposal, which represents the existing execution bank specified on the journal.
5.2.2 PREPARATION
To open a detailed payment journal view, select the payment journal in the overview and click the
Lines button.
The initial status of payments in a newly created journal is Editable, which indicates that the
payments can edited or deleted. E.g., it is possible to change bank account information, add/remove
settlements to payments lines and delete lines, which should not be included in the payment batch.
Furthermore, it is possible to add manual payments, simply by clicking the New button [CTRL+N] and
filling in the required payment information.
Note: Payment amount can only be altered directly on manual payment, i.e. payment without settlements.
If a payment has settlements, the total payment amount can be changed by editing the settle amount on
the individual settlement lines in the settlement grid
The settlement grid allows the user to alter the settlements quickly, without leaving the payment
journal. E.g., it is possible to quickly add or remove settlements with 1-2 mouse clicks. Furthermore,
it is possible to edit the settlements directly from the settlement grid, allowing the user to specify
|Payments 42
missing payment ids or change the amount to settle (thereby changing payment amount); all without
leaving the journal.
The advanced button opens a designated settlement form, in which the more advanced settlement
actions, like changing cash disc, can be completed.
When the settlement form is closed, the amount and advice is automatically updated based on the
settled open invoices.
|Payments 43
5.2.3 VALIDATION
From leaving the AX environment to being executed by the intended execution bank, processing of
payments can be done in several ways.
Depending on, whether the payment journal requires approval or not (determined by the execution
bank), the user has the option to either Validate or Transfer the journal using the respective buttons
from the menu.
In both cases, the first part of the payment process is to validate the payment information of the
payment journal being processed. This validation ensures that payment information is adequate and
will be accepted by the execution bank upon being received and processed in the external systems
of the bank.
Payment lines, which does not meet the bank requirements, will be marked as Erroneous.
Furthermore, the system will add a small descriptive log, that explains the nature or the error and a
hint to what needs to be corrected. This log can be seen by hovering the mouse cursor over the small
error icon, that is visible in the payment grid’s left-most column. A quick log view is also available in
the FactBox pane to the right
Note: Most lines in the log will have a small blue question mark icon next to the text message. Clicking the
questing mark redirects the user to the Banking knowledge base site, which sometimes offers additional
error details.
When the necessary corrections have been made, the user can click the Validate or Transfer button
once more to validate the now corrected journal. Once all payments are validated successfully, the
journal will enter the next phase, which includes making the journal non-editable, which ensure that
users cannot edit the now validated payment information.
|Payments 44
Once the journal has entered the non-editable state, it can only return to editable state by using
clicking the Cancel button from the menu. This button is available to users that have been assigned
the AMC Banking manager role.
5.2.4 APPROVAL AND TRANSFER

If the payment journal does not require approval, a bank file is returned and saved locally. In addition,
the payment transactions change to status Transferred. The user is now responsible for the physical
file transfer to the bank, e.g. by uploading the created payment file in the bank’s online web system.
If the payment journal does indeed require approval, the payment transactions instead change to
status Approvable, which allows the approval users to access the Approval button menu. Here they
have the possibility to either Approve or Reject the complete payment journal.
Clicking the Approve button will open a small journal approve dialog in which the approver can
specify username and password.
Rejecting the journal will return the journal into editable mode
Once the required approvals have been applied, the journal is transferred automatically. If a host-
to-host solution has been established with the bank, the bank file will be transferred directly to the
bank without further user involvement required. Alternatively, the approved bank file is returned
and saved locally, leaving the physical file transfer responsibility to the users. In both cases, the
payment transactions change to status Transferred.
5.2.5 POSTING
Once the payments have been transferred, the next step is to post the payments. To post the
payment journal immediately, as opposed to waiting for a payment notification from the bank, use
the Create posting proposal button. This will open a post dialog, where users can decide what to do
with erroneous payment transactions, which posting journal type to create the proposal from and
whether to attempt immediate posting of the created posting proposal
|Payments 45
Erroneous payment can either be deleted or moved to a new payment journal, wherefrom the
required corrections can be applied and the payments can be reprocessed.
If posting is instead postponed until the bank has confirmed the execution of the payments, then
users will sometimes experience, that some payments have been rejected by the bank. In that case,
users will usually not be able to delete the erroneous payments, because the journal enters a non-
editable state once transferred.
To remove the erroneous payment lines, use Functions > Move. The move functionality allows
moving the erroneous transactions to a new payment journal, wherefrom the required corrections
can be applied and the erroneous payments can be reprocessed
|Payments 46
5.3 EMAIL ADVICE
If the electronic advice included in the payment file is inadequate, it is possible to print and send an
additional email advice. Email advice is activated from the customer or vendor form by specifying,
an email address and an email template.
Using email advice has the great advantage, that there is no limit to the number of invoices, which
can be included in a single advice. The advice functionality uses standard AX email functionality,
making it possible to create language specific email templates, which resemble the language of the
receiving vendor. Standard email functionality also offers the possibility to use placeholders in the
email body, which can offer a more personal touch to the email message.
Available placeholders are:
Placeholder Meaning
%Custname% Customer’s name
%Vendname% Vendor’s name
|Payments 47
Furthermore, it is possible to choose the advice file type and choose an alternative report design, if
the default design is not adequate. This allows customers to quickly create own email advice designs.
Printing and sending of email advices can be done manually from the payment journal overview or
inside the individual payment journals. To print and send the email advice, click Print > Payment
advice
If payment advice is activated from inside the journal, a dialog is presented, allowing the user to
decide the print destination.
If payment advice is activated from the payment journal overview, outside the journal, the Banking
module will automatically loop through all the payment transactions related to the selected payment
journal, and send email advices to customers and vendors, which has email advice enabled.
It is possible to skip the manual email advice process, by enabling Auto send advice from the
Payments tab of the parameter setup (see 4.1.1). If auto sending of email advice is enabled, the
email advices are printed and sent once a payment journal has been successfully transferred.
5.4 ADDITIONAL FUNCTIONS

The payment journal has a few additional functions, which can be helpful. Especially if posting is
done directly from the payment journal, and therefore does not rely on bank return files. The
functions are available from the Functions menu
|Payments 48
The menu items have the following functions:
Menu item Function

Transactions A link to standard AX’s transactions form, which can be effectively used to get a detailed list of payees’
transactions.
Cancel Used to cancel the payment journal. This option is only available to trusted personnel, which has been
assigned to the AMC Banking manager security role
Move Used to move lines to another payment journal. This option is useful, if payments in the journal has
been marked as erroneous, as this blocks further processing of valid/accepted payments. In such
cases, the erroneous payments can be moved to a separate journal, allowing further processing of the
accepted payment, while allowing reprocessing of erroneous payments in a separate payment batch.
Update payment date Easy way to update several transactions’ payment dates simultaneously
|Payments 49
6 PAYMENT NOTIFICATIONS
Payment notifications reflect the credit and debit transactions, which have been physically posted
on the bank accounts in the bank. This section covers the processing of payment notification, from
the initial import to the final posting inside AX.
The overall goal when importing and processing payment notification, is to match, settle and post
physical bank transactions with payments and/or open transactions in the AX environment.
In earlier versions, payment notifications where restricted to banks, which could provide designated
payment notification files. The new version offers this facility to all customers, who can receive
simple bank account statements. This means that payment notification processing is available to a
vast increased number of customers, e.g. customers from countries with limited banking
infrastructure.
6.1 IMPORT
For more info on importing return files, please see separate Importing bank return files document
Imported payment notifications are matched against the own bank accounts, registered in the
Banking module (see 0). If a matching bank account is identified, the related company setup is used
to determine in which company to import the payment notification in, resulting in a posting journal
being created in the respective company.
6.2 POSTING JOURNAL

The posting journal is used to match and settle bank transactions against either payment journal
payments or open customer/vendor transaction, and is opened from AMC Banking > Journals >
Posting journal.
|Payment notifications 50
The posting journal overview have the following fields:
Section Meaning
In use Specifies whether the journal is in use by either the system or a user
Company The company, in which the journal belongs
Name of journal Name of the journal configured in Setup > Journals > Journals
Description A brief description of the journal and its content
Journal type The type of journal. Typically, either customer payment or vendor disbursement, depending on the imported
transactions
Lines The total number of lines in the current payment suggestion.
Ready The number of processed lines, which are ready for posting
Created date and time The journal’s creation date and time
To open a journal, select a journal and click the button Lines.
The posting journal contains two main parts, the top grid containing the individual payment and the
bottom grid containing the current payment’s settlements.
Each payment is stamped with a color code, which allows the user to quickly get an overview of
which payments, that have already been processed and which payments that require further
attention.
6.2.1 AUTO MATCH
During the import of payments, unless disabled, the Banking module performs an automatic match
of the payments. The auto match can also be executed manually on either journal or transaction
level from the Auto match menu.
Regardless of whether the auto match was executed automatically or manually, the individual lines
will be marked with a match level, which specifies with which certainty the match was found.
Level Match criterion

Rule (Turquoise) A rule level match is achieved if the payment was identified from user defined search string
configuration
High (Green) A high-level match is achieved if the payment was identified from either:
✓ Payment ID (1st priority)
✓ Payment reference (2nd priority)
✓ Invoice number (3rd priority)
Medium (Yellow) A medium level match is achieved if the payment was identified from either:
✓ Customer account no (4th priority)
✓ Our account number (5th priority)
✓ Customer name (6th priority)
✓ Customer bank account (7th priority)
Low (Red) A low-level match is achieved if the payment was matched against a customer or vendor, but was not
able to identify, which open invoices/transactions to settle.
In general, a low match always originates from either a rule, high or medium match, but has been
degraded, because the settlement could not be completed, e.g. because of amount differences
User (Blue) If the user manually settles the transactions or changes status to Ready, the transaction is marked
with match level User.
None (White) The auto match was not executed or was not able to match the payment.
The Banking module allows creating and utilizing own developed customer speci fic auto match classes. I.e.
it is possible to tamper with the individual match levels; hence, they can differ from the description above.
6.2.2 MANUAL SETTLEMENT

If the auto match is not able to identify a bank transaction’s related customer/vendor and invoice(s),
it is possible to carry out a manual settlement.
It is also possible to post a payment without settling it, e.g. if it is a prepayment. In that case, the user
can change the payment’s status field value to Ready.
To initialize manual settlements, click one of the two buttons in the settlement grid’s tool bar.
Clicking the Settlement button will open an external settlement form, which allows the user to settle
the bank transaction against open invoices in AX.
Clicking the Payment button will open an external settlement form, which allows the user to settle
the bank transaction against payments, which have been executed from the payment journal (see
5.2). The original payment thereby works as an indirect link to one or more open invoices in AX.
In both the regular settlement form as well as the payment settlement form, invoices that have
already been settled elsewhere, will be marked with a tiny red lock. Thus, the user will not be allowed
to conduct a settlement of the invoice.
If the user wants to see where a locked invoice has been settled, it is possible to click the tiny lock
icon. Doing so will result in an infolog; describing in which company the where the settlement has
been done.
Once the user has marked the invoices or payments to settle and made sure that the total settlement
amount matches the payment amount (within max difference), clicking OK will carry out the
settlements.
As a new feature, the module allows automatic handling of payments exceeding the open invoices
available. This situation e.g. occurs if a customer mistakenly pays invoices twice, thereby exceeding
the expected payment amount (see example below).
Customer mistakenly pays both Payment exceeding expected

Customer receives invoice A + B Customer pays invoice A + B Customer receives invoice C
invoice B + C amount
Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice Invoice
A B A B A B C A B C A B C
When attempting to carry out a settlement, where the payment amount exceeds the settlement
amount, the user will be asked to confirm the amount difference, which will result in the original
payment being split into three different transactions.
1) A ledger/bank transaction reflecting the original posted bank transactions

2) A settled customer transaction reflecting the part of the payment, which could be settled
against open invoices
3) A not-settled customer transaction reflecting the remainder of the payment, which could
not be settled
6.2.3 CASH DISCOUNT

If a customer has been granted cash discount, the auto match routine and settlement functionality
expect the customer to utilize the cash disc, by deducting the cash disc from the invoice amount.
This is of course only true, if the payment date does not exceed the cash disc date.
If the customer does not utilize the cash disc, or if the customer utilizes the cash disc, but the cash
disc date has been exceeded, the auto match will consider this an amount difference. Thus, an
obtained match will be degraded to a low-level match.
Should the user decide to accept the customer’s payment despite of the amount differences caused
by incorrect utilized cash disc, the settlement form allows modifying the expected cash disc easily by
using the designated cash disc fields as shown below.
Depending on how the cash disc has been incorrectly utilized, there several approaches, which can
be used to quickly accept the payment differences they cause.
✓ Customer does not utilize granted cash disc

Change Use case discount value from Normal to Never
✓ Customer utilized cash disc despite cash disc date being exceeded
Change Use case discount value from Normal to Always
✓ Customer utilizes cash disc but utilizes incorrect cash disc amount
Change Cash discount amount to utilized cash disc amount
✓ Customer utilizes cash disc despite not being granted cash disc
Change Cash discount amount to utilized cash disc amount
6.2.4 ADDITIONAL FUNCTIONS

The posting journal has several functions, which can be used to ease the process, getting from import
to posting. The functions are available from the Functions menu
The menu items have the following functions:
Menu item Function

Search string Quickly initiate and add search string record based on the current selected record
Move Used to move lines to another posting journal
Delete Easy way to delete many transactions, which can take very long, when done using the default delete
functionality
Renumbering Used to regenerate the voucher numbers in the journal. This is e.g. useful to ensure using the lowest
possible voucher numbers when using a continuous voucher series
Exchange rate Allows updating exchange rates per currency/date. Useful if the bank is not able to provide the
exchange rates related to the payments
Update payment date Easy way to update many transactions’ dates
6.2.5 POSTING
To post a posting journal, all transactions are required to have status Ready. This status is
automatically set when settling the transactions (automatically or manually), but can also be set by
the user, if the transaction is not to be settled.
The post method utilizes standard AX’s own posting functionality, meaning that the posting
functionality also includes a validation. This ensures that all transactions meet the posting
requirements configured throughout AX.
7 ACCOUNT STATEMENTS
Account statements reflect the movements on the bank account, but how the account statement is
processed and utilized, often depends on the individual customer and the country in which the
customer resides. In some countries, the account statement is the basis for the posting the credit
and debit movements in the ERP system, while account statements are used for account
reconciliation in others.
This chapter will primarily focus on the process of account reconciliation, but it is also possible to use
account statements as a posting foundation. In that case, the account statement will also enter the
system as payment notifications (see 6).
The overall goal of the bank account reconciliation is to ensure that the posted ledger transactions
in AX reflect the physical movements on the bank account, thereby also ensuring that balances in AX
corresponds with the balances on the bank accounts.
7.1 IMPORT
For more info on importing return files, please see separate Importing bank return files document
Imported account statements are matched against own bank accounts, registered in the Banking
module (see 0). If a matching bank account is identified, the related company setup is used to
determine in which company to import and create the account statement and the related
transactions.
|Account statements 57
7.2 RECONCILIATION
To start reconciling the bank account(s), open the list of own bank account from AMC Banking >
Common > Own bank accounts.
The own bank account grid contains two fields furthest to the right, Last date and Reconciled. The
two fields provide a quick overview on which bank accounts that requires reconciliation. The Last
date field holds the date of the latest registered movement on the bank accounts. The Reconciled
field contains a small icon, which indicates whether the bank account has been fully reconciled. If
reconciliation is required, a small red cross will be displayed, but once the account is reconciled, a
green check mark will appear instead.
The bank account overview provides two reconciliation options:
1) Reconciliation across bank account statement (recommended)

2) Reconciliation per bank account statement
To reconcile across statements, simply click Reconcile, which will open the reconciliation form.
To reconcile one statement at a time, instead click Bank statements, which will open a list of
statements related to the selected bank account.
The account statement overview contains a Reconcile button, which will open the same
reconciliation form as can be opened from the bank account overview. In this case, though, the
reconciliation form will only include bank transactions related to the current selected account
statement.
The reconciliation form is built using a bank and a ledger section. The bank section contains a list of
imported bank transactions and the ledger section contains a list of ledger transaction registered on
the bank account’s offset account.
Initially the form will open using Unreconciled view, which will display the bank and ledger
transactions, which have not yet been reconciled. Two further view options exist; Reconciled
showing only reconciled transactions and All showing both reconciled and unreconciled transactions.
7.2.1 AUTOMATIC RECONCILIATION

To start an automatic account reconciliation run, click the Auto reconcile button. This will open a
small dialog allowing the user to enter a few criteria, which decides the behavior of the automatic
reconciliation.
Option Behavior
Allow “one-to-many” reconciliations Specifies whether the automatic reconciliation should be allowed to settle a single
bank transaction against multiple ledger transactions
Note: Ledger transactions are required to have the same voucher or document
number
Allow “date-amount” reconciliations Specifies whether the automatic reconciliation should be allowed to reconcile
transaction solely on amount and date.
Allow posting date difference Specifies the number of days that bank and ledger dates can differ
Once the behavior of the automatic reconciliation has been decided, click the OK button to initiate
the reconciliation functionality. The automatic reconciliation will loop through the bank transaction
displayed in the form, and will attempt to match each bank transaction against AX ledger
transactions. When the reconciliation finishes, the results are displayed in an infolog.
The automatic reconciliation functionality will categorize the reconciliations into three levels,
depending on the certainty of the match
Value Meaning
High (Green) High reconciliation status is attained if a ledger transaction with for instance a unique payment
reference figuring in both the transaction of the bank and in Dynamics AX is found.
Medium (Yellow) Medium reconciliation status is attained if the posting text of the bank completely or partly contains
sequences recognizable in a ledger transaction in Dynamics AX. Also, the original basis of the ledger
entry is examined on the transaction so that a vendor payment having created an offset transaction on
the ledger account, for instance, is found if just the name or number of the company is found in the
posting text of the bank.
Low (Red) Low reconciliation status is attained if only the date and the amount on the bank transaction are the
occasions of the reconciliation against the ledger transaction.
The reconciled bank transactions and ledger transactions will automatically disappear from the
Unreconciled view. To see the reconciled transactions, switch to the Reconciled view.
Switching to Reconciled view will result in a new color code Level column on the left side of the grid.
The added column shows the match level of the individual transactions.
In addition, when selecting a reconciled transaction, all transactions related to the current
reconciliation, whether bank or ledger, will be marked in green. This allows the user to get a quick
overview of the current reconciliation. Furthermore, it is possible to show Only current
reconciliation, by checking or unchecking the check boxes above the two grids.
7.2.2 MANUAL RECONCILIATION

The user can reconcile bank transactions, which could not be reconciled automatically, manually.
This is done by marking the bank and ledger transactions to reconcile and clicking the Reconcile
button from the menu. Like the automatic reconciliation, the reconciled bank transactions and ledger
transactions will automatically disappear from the Unreconciled view. To see the reconciled
transactions, switch to the Reconciled view.
It is tempting to mark several bank and ledger transactions simultaneously to finish the reconciliation
in the fewest steps possible. However, we do not recommend this approach, as it quickly leads to a
loss of overview and confusing reconciliations. Furthermore, unreconciling a reconciled transaction
would result in the need to unreconcile all other related transactions as well.
7.2.3 LEDGER PROPOSAL

When reconciling transactions manually, situations where the bank and ledger amount does not
match, is likely to occur.
The ledger proposal is used to handle such situation. It is possible to add amount difference to the
ledger proposal, but it is also possible to add bank transactions, if they have not been registered on
the ledger side at all.
To add either the bank transaction or the amount difference to the ledger proposal, use the
respective buttons from the proposal part of the menu.
Once a transaction has been added to the ledger proposal, the Proposal button will be enabled,
allowing the user to enter the ledger proposal.
When the user is satisfied with the ledger proposal, the proposal can be transferred to an existing or
new journal from where the posting can be completed by clicking the Transfer to ledger button. The
transfer dialog also contains a Post option, which allows the user to automatically post the created
ledger journal
As the ledger part of the reconciliation form is showing data directly from standard ledger tables,
transactions posted using the ledger proposal, i.e. on the bank account’s offset account, is available
immediately by refreshing the form.
7.3 REPORTS
The Banking module contains two reports to support the bank account reconciliation process, which
are available from the Print menu.
7.3.1 RECONCILIATION REPORT

To document the account reconciliation, it is possible to print out a reconciliation report by clicking
the Reconcile report button from the own bank account list page form.
This will result in a small dialog, in which the user can specify a date interval and a so-called
Viewpoint allowing, seeing the either reconciliation from Current or Historical view.
The box From date is automatically specified using the latest of the two dates: account reconciliation
start date set on selected bank account or the start date of current fiscal year. Account reconciliation
start date is indicated under AMC Banking > Common > Own bank accounts > Maintain > Edit >
Reconciliation > Start date.
The box To date must be filled in with the date for which you wish to show the reconciliation. Be
advised that the start and end date must be from the same fiscal year and that opening entries are
created since problems with the ledger balance would arise in the report otherwise. The
reconciliation report is constructed as follows:
7.3.2 FORECAST REPORT

It is possible to print a forecast report, which simulates the near future cash flow. The forecast is
calculated dynamically, based on the latest account statement date from the bank as well as both
realized and unrealized customer and vendor payment
To print the forecast report, click Print > Forecast report in the own bank account list page.
8 APPENDIX
8.1 AGGRESSIVE CREDIT NOTE ACCUMULATION

Aggressive credit note accumulation offers the possibility to deduct future credit notes from similar
payments despite the credit notes being due later than the payments.
This section describes step-by-step, how a list of open invoices is handled and accumulated using the
aggressive credit note accumulation method.
Open invoices
Due date Amount

01.01 -500,00
08.01 2.000,00
10.01 1.500,00
10.01 -1.200,00
12.01 400,00
15.01 -500,00
31.01 800,00
31.01 -2.000,00
Current date = 05.01 | Date range 05.01 – 20.01
Credit notes lie outside date range; both prior and afterwards. By enabling the [Aggressive] credit note mode,
the module will attempt to pair credit notes (even though outside due range) with similar payments, while
ignoring due date differences.
|Appendix 67
The module will pair the credit notes with the earliest payment, which exceeds the credit note’s amount.
Open transactions
01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015 31.01.2015

-500 2.000 1.500 -1.200 400 -500 800 -2.000
Removing payments outside date range (...but keeping credit notes)
01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015 31.01.2015

-500 2.000 1.500 -1.200 400 -500 800 -2.000
Credit note outside Payment outside Credit note outside
date range date range date range
Credit note accumulation:
01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015

-500 2.000 1.500 -1.200 400 -500 -2.000
No payment large
enough
Result:
08.01.2015 10.01.2015 12.01.2015 31.01.2015

300 1.000 400 -2.000
01.01.2015 10.01.2015
-500 1.500
08.01.2015 15.01.2015
2.000 -500
10.01.2015
-1.200
|Appendix 68
8.2 CHARTS
From the overview of own bank accounts, it is possible to get a graphical view of data related to the
individual bank accounts.
Currently the module includes three charts, which can all be opened from the menu
- Balance: Provide an overview of the progression of the bank account’s balance over time
- Costs: Provides an overview of costs related to e.g. exchange fees, regular fees, interests etc.
- Post: Provides an overview of the daily movements on the bank account
8.2.1 TROUBLESHOOTING
If the chart is opened with wrong parameters (e.g. if bank account number has not been registered
on the web service, specified in parameter setup), the following errors appear.
|Appendix 69
The chart all utilize some external scripts, which generate the individual charts visible in Internet
Explorer. If the chart tab appears blank when opened, it could be caused by restrictions in Internet
Explorer. In that case, Internet Explorer security settings need to be configured to allow running the
external scripts.
One way to accomplish this is to follow the steps below:
✓ Open Internet Explorer

✓ Select Internet Options from the menu and go to the Security tab
✓ Add the web service URL from the parameter form to the list of Trusted sites
8.3 POSTING SCENARIOS

The exchange rate when importing status files (DEBMUL) for the different posting scenarios can be:
Own account Payment Posting MSD Posting CUR Exchange rate

currency currency From file
DKK DKK DKK DKK 100, no
DKK USD DKK USD DKK/USD rate
EUR EUR DKK EUR DKK/EUR rate
EUR USD DKK EUR DKK/EUR rate
8.4 DEMO RETURN FILE

As a new feature, it is possible to create a demo account statement, based on the open invoices in
the AX environment. The feature is initialized from Setup > System > Demo return file.
|Appendix 70
The demo feature makes it possible to quickly set up a demo on the fly, without the need for an
active, working bank agreement, without deciding on certain file formats and without the need to
complete excessive setup. Thus, it is possible to create a realistic demo file based on the customer’s
own data.
Activating the menu item, opens a small dialog, where the user is asked to choose the bank account
to base the demo data on, and a file path where the demo file should be saved.
Once the OK button is clicked, the demo functionality will loop through the AX environment’s open
invoices, and attempt to create demo transactions, allowing users to test various reconciliation and
auto match scenarios.
To keep the demo simple, both bank accounts as well as open invoices are restricted to the company’s
currency only.
When finished looping through the open invoices, the demo file is created and an infolog is returned,
informing which of the various demo scenarios that were successfully created
|Appendix 71
|Appendix 72
9 US LOCALIZATIONS
If the US localizations model has been installed, the Banking users will have access to US specific
content and functionality, which is not part of the Banking foundation model.
9.1 POSITIVE PAY JOURNAL

The primary US specific feature is the Positive pay journal, which is added to the Journals section in
the Banking workspace.
The Positive pay journal is used to verify physical cheques, to prevent cheque fraud, and is opened
from AMC Banking > Journals > Positive pay journal.
|US Localizations 73
From the journal menu, the user is offered a few options like creating new Positive pay files, as well
as viewing, editing and processing existing Positive pay transactions. To see the details of the
individual journals, select a journal and click the Lines button.
The journal form contains the following fields:
Section Meaning
Positive The company indicates the id of the company, where the payments are processed from
Positive pay format The bank set up under Setup > Banks > Banks, which are to receive the positive pay transactions
Own account The positive pay related bank account, which is also the bank account, from which the cheques are executed.
Positive pay number Number identifying the journal, like the journal number, known from other journals
Lines Shows the total number cheques in the journal
Voided Shows the number voided cheques
Cutoff date Positive pay cutoff date
Confirmation number The confirmation number, which is provided by the bank upon receiving the positive pay file
File status Status of the positive pay journal/file
9.1.1 CREATION
To create Positive pay journals, click the Add > Positive Pay. Doing so, will open the Add payments
dialog
The dialog contains only two fields and a range section, which can be used to limit the cheques being
added to the journal.
Section Meaning
Own account The bank account on which to create positive pay transactions. The bank account’s offset account is
used to find cheques that are going to be executed from the bank account
Cutoff date A simple transaction date, which is used to determine which cheques to add to the journal
Once the desired ranges have been specified, click the OK button to generate the Positive pay journal
and transactions.
9.1.2 TRANSFER
Use the transfer button to validate the data of the individual Positive pay transactions. If all
transactions are validated successfully, the Positive pay file is created, allowing users to forward the
physical file to the bank.

Amc Banking 2012 5 For Dynamics Ax 2012 User Guide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Amc Banking 2012 5 For Dynamics Ax 2012 User Guide

Uploaded by

Copyright:

Available Formats

USER GUIDE

AMC Consult A/S

For a complete list of banks, please visit:

Import and posting of payment notifications

Import and reconciliation of bank account statement

✓ The latest version of the Banking module should be installed

The fields on the payments tab have the following features:

The fields on the posting tab have the following features:

The fields on the log tab have the following features:

The fields on the fast tabs have the following features:

The fields on the fast tabs have the following features:

Note: Individual fee transactions will still be imported

4.3.1 COMPANY SETUP

The fields in the grid have the following features:

4.4.1 BANK ACCOUNTS

4.6.1 ADVICE TYPES

- Compressed: Comma separated invoice numbers

This setup will create an advice like this:

“Invoices: 123456789, 321654987, 4654231….”

Most payment file formats allow 35 characters of text per line.

4.7 PAYMENT TYPE PRIORITIES

Furthermore, it is possible to create language specific transactions texts. E.g., it is possible to

4.11 SECURITY ROLES

5.2 PAYMENT JOURNAL

5.2.4 APPROVAL AND TRANSFER

Available placeholders are:

5.4 ADDITIONAL FUNCTIONS

Menu item Function

6.2 POSTING JOURNAL

To open a journal, select a journal and click the button Lines.

6.2.1 AUTO MATCH

Level Match criterion

6.2.2 MANUAL SETTLEMENT

Customer mistakenly pays both Payment exceeding expected

1) A ledger/bank transaction reflecting the original posted bank transactions

6.2.3 CASH DISCOUNT

✓ Customer does not utilize granted cash disc

6.2.4 ADDITIONAL FUNCTIONS

Menu item Function

The bank account overview provides two reconciliation options:

1) Reconciliation across bank account statement (recommended)

7.2.1 AUTOMATIC RECONCILIATION

7.2.2 MANUAL RECONCILIATION

7.2.3 LEDGER PROPOSAL

7.3.1 RECONCILIATION REPORT

7.3.2 FORECAST REPORT

8.1 AGGRESSIVE CREDIT NOTE ACCUMULATION

Due date Amount

Current date = 05.01 | Date range 05.01 – 20.01

01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015 31.01.2015

Removing payments outside date range (...but keeping credit notes)

01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015 31.01.2015

Credit note accumulation:

01.01.2015 08.01.2015 10.01.2015 10.01.2015 12.01.2015 15.01.2015 31.01.2015

08.01.2015 10.01.2015 12.01.2015 31.01.2015

- Post: Provides an overview of the daily movements on the bank account

One way to accomplish this is to follow the steps below:

✓ Open Internet Explorer

8.3 POSTING SCENARIOS

Own account Payment Posting MSD Posting CUR Exchange rate

8.4 DEMO RETURN FILE

9.1 POSITIVE PAY JOURNAL