banking 7 user guide · 1/25/2019 · like many of the other modules in ax, the banking module...
TRANSCRIPT
AMC Consult A/S January 25, 2019 Banking 7
USER GUIDE
AMC BANKING DYNAMICS 365 FOR OPERATIONS
|Introduction 2
CONTENTS
Introduction...................................................................................................................................5
Facilities .........................................................................................................................................6
Prerequisites..................................................................................................................................7
Workspace .....................................................................................................................................8
4.1 About .................................................................................................................................. 10
Setup .......................................................................................................................................... 11
5.1 Parameters ......................................................................................................................... 11
5.1.1 Payments ............................................................................................................. 11
5.1.2 Posting ................................................................................................................. 12
5.1.3 Web service ......................................................................................................... 13
5.1.4 Direct debit .......................................................................................................... 14
5.2 Banks .................................................................................................................................. 15
5.2.1 Setting.................................................................................................................. 17
5.2.2 Bank holidays ....................................................................................................... 18
5.2.3 Prices ................................................................................................................... 19
5.3 Own bank accounts ............................................................................................................ 19
5.3.1 Company setup .................................................................................................... 22
5.4 Customers and vendors...................................................................................................... 23
5.4.1 Bank accounts ...................................................................................................... 25
5.5 Journals .............................................................................................................................. 28
5.6 Advice ................................................................................................................................. 29
5.7 Payment type priorities ...................................................................................................... 31
5.8 Search strings ..................................................................................................................... 32
5.8.1 Cleanup ................................................................................................................ 34
5.9 Transaction texts ................................................................................................................ 34
5.10 Auto match ......................................................................................................................... 35
5.11 Workflows .......................................................................................................................... 37
5.12 Security roles ...................................................................................................................... 37
Payments .................................................................................................................................... 38
|Introduction 3
6.1 Prerequisites....................................................................................................................... 38
6.2 Payment journal ................................................................................................................. 38
6.2.1 Creation ............................................................................................................... 39
6.2.2 Preparation .......................................................................................................... 41
6.2.3 Validation ............................................................................................................ 43
6.2.4 Approval and transfer.......................................................................................... 45
6.2.5 Posting ................................................................................................................. 45
6.3 Email advice ........................................................................................................................ 46
6.4 Additional functions ........................................................................................................... 47
Direct debit withdrawals ............................................................................................................ 49
7.1 Prerequisites....................................................................................................................... 49
7.2 Direct debit journal ............................................................................................................ 49
7.2.1 Creation ............................................................................................................... 50
7.2.2 Preparation .......................................................................................................... 51
7.2.3 Validation ............................................................................................................ 51
7.2.4 Transfer ............................................................................................................... 51
7.2.5 Posting ................................................................................................................. 51
7.3 Email advice ........................................................................................................................ 51
7.4 Mandates ........................................................................................................................... 51
7.4.1 Physical mandates ............................................................................................... 52
7.4.2 Electronic subscriptions ....................................................................................... 52
Payment notifications ................................................................................................................ 56
8.1 Import ................................................................................................................................. 56
8.2 Posting journal ................................................................................................................... 56
8.2.1 Auto match .......................................................................................................... 57
8.2.2 Manual settlement .............................................................................................. 58
8.2.3 Cash discount ...................................................................................................... 60
8.2.4 Additional functions ............................................................................................ 61
8.2.5 Posting ................................................................................................................. 62
Account statements ................................................................................................................... 63
|Introduction 4
9.1 Import ................................................................................................................................. 63
9.2 Reconciliation ..................................................................................................................... 63
9.2.1 Automatic reconciliation ..................................................................................... 65
9.2.2 Manual reconciliation .......................................................................................... 67
9.2.3 Ledger proposal ................................................................................................... 67
9.3 Reports ............................................................................................................................... 69
9.3.1 Reconciliation report ........................................................................................... 70
9.3.2 Forecast report .................................................................................................... 71
Appendix .................................................................................................................................... 72
10.1 Charts ................................................................................................................................. 72
10.2 Posting scenarios ................................................................................................................ 72
10.3 Demo return file ................................................................................................................. 72
10.4 Aggressive credit note accumulation ................................................................................. 74
|Introduction 5
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
|Facilities 6
FACILITIES The Banking module covers four 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.
Direct debit withdrawals
AMC Banking includes facilities for automatic withdrawal of funds from customer bank accounts
based on the customer invoices registered in the system
The direct debit functionality handles every step of the withdrawal process, from acquiring physical
or electronic withdrawal mandates, from sending the actual withdrawal instructions to finally
settling and posting the customer invoices.
|Prerequisites 7
PREREQUISITES To be able to complete the setup and actions described in this manual, there are a few prerequisites
✓ The Banking module should be installed
✓ A valid Banking license should exist, and the necessary license setup should have been
completed
|Workspace 8
WORKSPACE Like many of the other modules in AX, the Banking module includes a designated workspace, which
can easily be accessed from the central AX dashboard.
Clicking the AMC Banking tile, forwards the user to the Banking workspace page, which offers easy
access to important data and the core functionalities that revolves around Banking related processes.
The workspace is divided into four sections
|Workspace 9
1) Summary
The summary section allows the user to initiate the daily tasks, increasing the productivity
related to actions like initiating payments and importing bank return files
2) Journals and transactions
Tab section offering an overview of the tasks currently in in process, allowing the user to
quickly initiate actions, when required
3) Statistics
Section offering small, graphical BI charts, offering a quick overview of the overall usage of
Banking. Clicking the match level chart will open statistics in numbers, telling how efficient
the auto match is being used and an estimate on saved time.
4) Links
The Links section, contains links to the most common used pages in the Banking module.
E.g. it offers quick access to the bank list, the customers own bank accounts as well as the
payee setup pages.
|Workspace 10
4.1 ABOUT
Clicking the About button in the top left corner, allows the user to see the exact version of the
Banking module installed in the current Dynamics 365 environment
|Setup 11
SETUP
5.1 PARAMETERS
The module’s basic parameters are set up from AMC Banking > Setup > Parameters.
5.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.
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
|Setup 12
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
Attachments File directory, in which to store attachment files when e-mailing payment advices. The file
directory should be accessible from the server, as it is the server, that creates the advice
attachment files.
5.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
Split payments 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
Use old match interface As of Banking 7.4.0.0 a new auto match interface was introduced, deprecating old auto
match customizations and extensions. To prevent old customization from stop working, the
old interface is still there, and can be reactivated by checking this checkmark.
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
|Setup 13
Grace period Number of days to add to cash discount date, and thereby number of days to allow cash disc
even though overdue
5.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. Next
to the field, is an SSL certificate status indicator, which is continuously updated to reflect the
certificate status of the last web service connection.
- Locked: Certificate is trusted, and channel is secure
- Unlocked: 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
- Exclamation mark: Certificate is invalid, and channel is insecure. The Banking
module will block communication with untrusted web services
|Setup 14
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)
Login The username/login used when communicating with the license server and the web service
specified in the URL field. Username is specified when registering your AMC-Banking license
Password The password used when communicating with the license server and the web service
specified in the URL field. Password is specified when registering your AMC-Banking license
Date verified The date the license was last verified
Note: The license is automatically verified every 14 days
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
- Debug: All messages including “unstructured” messages (e.g. unhandled
exceptions)
5.1.4 DIRECT DEBIT
The payments tab contains setup specifically related to the process of automatic withdrawal of funds
from customer bank accounts via direct debit.
Field Description
Solution The options are:
- Plus
- Enterprise
URL The URL of the web service which handles the conversion of payments and bank files. Next
to the field, is an SSL certificate status indicator, which is continuously updated to reflect the
certificate status of the last web service connection.
- Locked: Certificate is trusted, and channel is secure
|Setup 15
- Unlocked: 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
- Exclamation mark: Certificate is invalid, 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)
Tax registration number Due to a general lack of consensus, on which field to use, when registering customers’ tax
registration number, you can set up, which field from the customer table that is used by the
D365 legal entity/company.
The options are:
- Tax exempt number
- ID number
- Organization number
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
5.2 BANKS
The general bank setup is set up from AMC Banking > Setup > Banks > Banks
When entering the bank setup page for the first time, the list of banks is empty. To add banks to the
list, click Select banks
To update the list of available banks, click Update banks. This will contact the bank data conversion
service and fetch an up-to-date list of banks made available by the service.
|Setup 16
To add banks, use the arrows to move banks from the Available (top) to the Selected (bottom) grid.
Once the preferred banks have been added, click Close to return to the bank setup page.
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.
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 Indicates whether bank requires approval when executing payments
Login Indicates whether bank requires signing in, when importing bank return files
Direct debit Indicate whether the bank is a direct debit bank, hence cannot be used for regular payments
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
Direct debit (only applicable on direct debit banks)
Mandate required Used to specify whether bank requires physical mandates
|Setup 17
Subscription required Used to specify whether bank requires electronic mandates
Credit card bank Used to specify whether withdrawals are done via a credit card solution
5.2.1 SETTING
Clicking Setting to open a page where additional bank setup can be configured.
The fields on the fast tabs have the following features:
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 the name of the payment file, that is later sent or uploaded to the bank.
Alternative sender Used to override the default sender name, which is otherwise fetched from standard AX
company setup
Advice Default advice, allowing to set up a joint advice layout on bank level, instead of having to set
up advice on each payee
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)
Direct debit (only applicable on direct debit banks)
File to bank (subscription) Used to specify where to save created payment files
Alternative tax registration
number
Used to override the default tax registration number, which is otherwise fetched from
standard AX company setup
Subsystem Used to set up which bank sub system to use for direct debit functionality
|Setup 18
5.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 these none-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 5.2).
The fields on the fast tabs have the following features:
Field Description
Calendar Identification of the bank holiday calendar
Description Brief description of the bank holiday calendar
Allow payments on weekends 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 19
5.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 5.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 page.
5.3 OWN BANK ACCOUNTS
The setup related to your company’s own bank accounts is opened from AMC Banking > Common >
Own bank accounts.
|Setup 20
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 9)
and for balance chart, cost chart and post chart (see section 10.1)
Clicking either New > Bank Account or Maintain > Edit, will open a separate, detailed bank account
setup page.
The fields on the fast tabs have the following features:
Field Description
Bank
|Setup 21
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.
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
Match class Field used to specify, which auto match class to use during auto matching of imported
transaction. The auto match class is responsible for testing the validity of the matches found
by the rules
If left blank, the auto match functionality will use the default auto match class, which is
distributed as part of the AMC-Banking module
Match rule setup Used to specify which set of auto match rules to use for identifying potential matching
payments and/or invoices in the system
|Setup 22
If left blank, the auto match functionality will use a default set of auto match rules in a strict
order from
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
Opening balance Used to specify the system account’s opening 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.
5.3.1 COMPANY SETUP
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
|Setup 23
Auto match Specifies in which companies to look for open invoices when the auto match functionality is
executed
5.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 pages are almost identical in relation to both design and
functionality. Having two setup pages, primarily serves to keep customers and vendors separate. The
following section will therefore in certain cases only cover the vendor setup page, 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 pages 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.
The status field in the grid have the following features:
Field Description
Status An image displaying the payment status of the vendor. The options are:
- [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
|Setup 24
- [None]: The vendor is enabled but has no bank related setup. The vendor’s open
transactions are included in payment process
- [Stop sign]: 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 page
The fields in the page 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
5.1.1 for more information
|Setup 25
Advice
Enable (File 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
Enable (Mail advice) Used to activate email advice for the payee
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 The report design to use when sending payment advices to vendor. The module includes
only one design, but this field can be used, if additional designs are created on the
customer-side
File format The SSRS file format to send the advice in
5.4.1 BANK ACCOUNTS
Customer and vendor bank accounts can be maintained either directly on the detailed
customer/vendor setup page or by clicking the Payment > Bank accounts button in the list page
menu.
|Setup 26
The fields in the page have the following features:
Field Description
Identification
Bank account Bank account identification
Name Name of the bank account
Bank account
Bank account number The account number that is assigned by the bank
Is IBAN Display field, indicating, whether bank account number is an IBAN account
Primary Display field, indicating, whether the bank account is the primary payee bank account
Bank account details
Routing number type Code identifying the type of the routing number
Routing number Routing number of 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.
Parent bank account Used to tie virtual bank accounts to their physical counterparts
Payment
|Setup 27
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)
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
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
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
Status
Active from Date wherefrom the bank account is active
Note: This field is only available/shown on vendor bank accounts
Active to Date whereto the bank account is active and thereby is disabled
Note: This field is only available/shown on vendor bank accounts
Status Display field, quickly indication, whether bank account is active based on active from and
active to fields
Note: This field is only available/shown on vendor bank accounts
Workflow status Bank account approval workflow status. If workflow has not been enabled, status is always
Active
|Setup 28
5.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 29
5.6 ADVICE
Electronic advices for payment files are set up from AMC Banking > Setup > Advice.
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.
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
5.6.1.1 COMPRESSED
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 30
5.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.
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 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
|Setup 31
• %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.
5.6.1.3 CLASS
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, which forces the
advice class to implement certain functionality.
5.7 PAYMENT TYPE PRIORITIES
When adding payments, users are presented with payment proposals, representing different
payment scenarios. Should the users find the default provided payment proposals inadequate, they
|Setup 32
can instead setup their own prioritized list of payment types from AMC Banking > Setup > Payment
type priorities.
On the left side, the priority page contains an overview of existing payment type priority lists. On the
right side, the page 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 priority lists exist, they will be included as individual payment proposals when adding payment,
provided they are not specified as User only or created by the current users.
5.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.
|Setup 33
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
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
|Setup 34
account statements to post bulk payment, which have been specified in earlier files. E.g. Lockbox
files (US) and FIK-indbetalinger (DK)
5.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. The button opens a simple dialog, in which the
user can specify Older than number of days.
Upon clicking the OK button, 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.
5.9 TRANSACTION TEXTS
The transaction text setup, which is reflected on the individual journal transactions’ Description field,
is set up from AMC Banking > Setup > Transaction texts
|Setup 35
The transactions text setup page 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.
5.10 AUTO MATCH
A new auto match interface has been introduced, which makes it much easier to customize the auto
match on the fly, without the need to develop code-wise changes.
To set up a custom auto match routine, open AMC Banking > Setup > Auto match
|Setup 36
The auto match setup page is used to create user-defined match routines, that consists of a set of
match rules, which can be enabled/disabled and prioritized as required and desired. A custom, user-
defined auto match routine can be very helpful to better fit the auto match to the bank information
provided on imported bank transactions. E.g. if a bank account only has transactions with payment
references, performance and time-consumption can most likely be optimized by disabling pointless
match rules like the customer name rule.
To create a new auto match routine, click the New button from the top menu. The new match routine
will initially reflect the default match setup, but can easily be customized from the grid menu, by
disabling (deleting) or by changing the priority of the individual match rules. It is also possible to add
new match rules, e.g. if custom developed match rules are available.
|Setup 37
In addition to the match rules in the grid, it is also possible to enable advanced sequential matching,
by changing the Advanced match value to Yes. When the advanced match is enabled, the match
routine will attempt to match a subset of the customer invoices sorted by due date.
Advanced matching should be used with caution, as it will increase the total time-consumption of
the auto match. Therefore, the advanced matching is best used in situations, where it is common for
customers to pay only a subset of the outstanding invoices, without providing the necessary
structured information, e.g. invoice numbers, that allows the system to determine, exactly which
invoices are being paid.
5.11 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.
5.12 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
|Payments 38
PAYMENTS This section covers the creation, approval and execution of payments.
6.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
6.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 a few 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.
The payment journal page 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
Transferred Shows the number of lines, which have been transferred to the bank
Received Shows the number of lines, which have been confirmed as received by the bank
|Payments 39
Validated Shows the number of lines, which have been successfully validated by the bank
Executed Shows the number of lines, which have been executed by the bank
Errors Shows the number of erroneous payment lines in the journal
Updated The date and time of the last journal update
6.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 enough to process customer payments.
To create a new payment journal and add payment lines, click either Add > Customer payments or
Add > Vendor payments. This will open a dialog in which basic ranges can be used to filter and limit,
which open transaction to include
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
In addition to the fields, which have been placed directly in the dialog, the user can further limit the
transactions, by adding user defines ranges, using the Filter button in the Records to include section.
This is also where e.g. cross company ranges can be activated and changed
Once the desired ranges have been specified, click OK to proceed to the payment proposal dialog.
|Payments 40
In the new two-part dialog, users are presented with different payment proposals. Each payment
proposal includes the exact same invoices, but represents different ways of processing, the found,
open vendor transaction and thereby also the final payments.
In the top part, the user can see and choose between the individual generated proposals. The bottom
part will show the individual payment transactions based on the selected payment proposal.
The system will generate and present payment proposal using only a single execution bank but will
also create proposals that can include multiple execution banks, e.g. a payment proposal offering
the cheapest way possible of executing the payments.
During the generation of the individual payments proposals, the system will automatically attempt
to determine bank accounts, payment types and other payment related information. The system
uses various data to determine the payment information, such as country of payee bank account,
invoice currency and available payment types. For an overview on how payment information is
determined, see separate Determine payment instruction document.
The individual payments proposals will usually differ based on the payment types available in the
various executing banks but can also be affected by user defined behavior parameters, which the
user can specify in the bottom part of the dialog.
Section Meaning
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
|Payments 41
- 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: See section 0
When the payment behavior parameters are changed, the system must regenerate the proposals
and therefore the Create button is disabled and instead the Refresh button is enabled. Clicking
Refresh, will regenerate the payment proposals end re-enable the Create button.
The top part of the payment proposal dialog contains two buttons, which is used to run checks, which
can be executed repeatedly on the individual payment proposals:
- Check payees: 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 balances: Checks whether the involved bank accounts have enough money to process
the payments, without resulting in a negative balance.
The balance is calculated using the bank account’s balance, and if the balance is being
exceeded, the check returns a warning,
To finish the payment proposal process and create the payments, select the desired payment
proposal and click Create. 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.
6.2.2 PREPARATION
To open a detailed payment journal view, select the payment journal in the overview and click Lines.
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 from the Add menu.
|Payments 42
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, placed in the bottom of the page, allows the user to alter 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 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 page, in which the more advanced settlement
actions, like changing cash disc, can be completed.
|Payments 43
When the settlement page is closed, the amount and advice is automatically updated, based on the
settled invoices.
6.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.
|Payments 44
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.
A quick log view is also available in the FactBox pane to the right
If the payment journal contains many lines and validation errors are scattered throughout the
journal, the display filter in the top-left corner can be used to filter transactions so only erroneous
lines are visible.
When the necessary corrections have been made, the user can click either the Validate or Transfer
button once more to validate the now corrected journal. Once all payments are validated
|Payments 45
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.
Once the journal has entered the non-editable state, it can only return to editable state by using
clicking Cancel. This button is available to users that have been assigned the AMC Banking manager
role.
6.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.
6.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, click
Create posting proposal. 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 46
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
6.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 page by specifying an
email address and an email template. See 5.4
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. Furthermore, 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 personalized touch to the email message.
|Payments 47
Available placeholders are:
Placeholder Meaning
%Custname% Customer’s name
%Vendname% Vendor’s name
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 5.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.
6.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
|Direct debit withdrawals 49
DIRECT DEBIT WITHDRAWALS This section covers the creation and execution of direct debit withdrawals. In addition, it covers the
creation of the required withdrawal mandates, whether electronic or physical.
7.1 PREREQUISITES
Customer 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
7.2 DIRECT DEBIT JOURNAL
The direct debit journal is used to create, and process withdrawals based on open customer
transactions and can be opened from AMC Banking > Journals > Direct debit journal.
From the journal menu, the user is offered a few options like creating new journals as well as viewing,
editing and processing existing direct debit journals
The payment journal page contains the following fields:
Section Meaning
Company The company indicates the id of the company, where the journal is processed from
Bank The bank set up under Setup > Banks > Banks, which is used to execute the batch/journal
Journal The id of the journal, which also works as a batch’s unique indicator.
Unlike most other journals, the journal id of the journal is not based on number sequences or voucher series.
The journal id is instead constructed from the execution company combined with a shared counter, which
ensures that 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
Transferred Shows the number of lines, which have been transferred to the bank
Received Shows the number of lines, which have been confirmed as received by the bank
Validated Shows the number of lines, which have been successfully validated by the bank
Executed Shows the number of lines, which have been executed by the bank
|Direct debit withdrawals 50
Errors Shows the number of erroneous payment lines in the journal
Updated The date and time of the last journal update
7.2.1 CREATION
To create a new direct debit journal, click the New button, and fill in the required fields. Once
created, select the journal and click Lines.
Click the Add button from the menu to add withdrawal lines to the journal. This opens a dialog, which
can be used to filter the open transactions to add to the journal.
Section Meaning
Due date A due date range added as convenient filter 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.
Click the OK button to add the customer transactions that fall within the specified filter ranges
|Direct debit withdrawals 51
7.2.2 PREPARATION
Preparation of a direct debit journal works like preparation of regular payment journal. For more
info see 6.2.2
7.2.3 VALIDATION
Validation of a direct debit journal works like validation of regular payment journal. For more info
see 6.2.3
7.2.4 TRANSFER
Transfer of a direct debit journal works like transferring of regular payment journal. For more info
see 6.2.4
7.2.5 POSTING
Posting of a direct debit journal works like posting of regular payment journal. For more info see
6.2.5
7.3 EMAIL ADVICE
Sending email advices to customers in a direct debit journal works like the equivalent functionality
of a regular payment journal. For more info see 6.3Error! Reference source not found.
7.4 MANDATES
A mandate is an acceptance from the customer, giving access to withdraw funds directly from the
customer’s bank account. There are two type of mandates
|Direct debit withdrawals 52
• Physical mandates
• Electronic subscriptions
7.4.1 PHYSICAL MANDATES
The mandate implicitly includes general rules as to the customer’s rights to cancel withdrawals as
well as obligations of the withdrawer to advice prior to the actual withdrawal etc.
To enable the use of mandates, open AMC Banking > Setup > Banks > Banks, select the withdrawal
bank and ensure that the Mandate required check box is checked
The Banking module utilized the standard direct debit mandate functionality, which is found in the
customer setup.
For more info, see: https://docs.microsoft.com/en-us/dynamics365/unified-
operations/financials/accounts-receivable/tasks/create-direct-debit-mandate-customer
7.4.2 ELECTRONIC SUBSCRIPTIONS
In this chapter we will discuss the subscription process. Like mandates, the subscription process is all
about getting access to withdraw funds from the customers’ bank accounts, but unlike mandates,
which are physical files/documents, subscriptions are instead electronic interchanges of mandate
information.
To enable the use of subscription, open AMC Banking > Setup > Banks > Banks, select the withdrawal
bank and ensure that the Subscription required check box is checked
Subscriptions are maintained from AMC Banking > Periodic tasks > Subscription
|Direct debit withdrawals 53
The form, from which subscriptions are handled, contains three grids.
1. The left most grid contains subscription which are ready to be processed
2. The middle grid contains pending subscriptions, which requires some kind of action to be
processed
3. The right most grid contains a list of active subscriptions, which allows withdrawals from the
related customers
7.4.2.1 PROCESSABLE SUBSCRIPTIONS
First step of adding an active mandate, is to add customer to the Processable subscriptions grid. This
is done by clicking the Select button from the grid’s top menu, which open a small pop-up window
from which inactive customer can be selected.
Once the customers have been selected, click the Close button to return to the subscription form.
To process the processable subscriptions in the list, click the Transfer button. This will activate a
validation of the customer and subscription data. If the validation is successful, an electronic
|Direct debit withdrawals 54
subscription file will be created, and the processed subscriptions will change state from processable
to pending, hence move from the list of Processable subscriptions to the list of Pending
subscriptions
7.4.2.2 PENDING SUBSCRIPTIONS
As the name indicates, the list of pending subscriptions contains subscriptions, which have not yet
been fully processed. There are basically two types of pending subscription.
The first type covers the subscriptions, which have been transferred and now awaits a bank response
confirming the completion of the subscription.
The second type covers unknown (active) subscriptions, which need to be linked to customers in the
system. Unknown subscriptions are typically created because of a bank response, containing
subscriptions, which cannot be identified by the data in the response. In that case a warning
messages will inform that an unknown subscription has been added to the list of pending
subscriptions
Pending subscription awaiting bank response can be recognized by the small clock icon on the left
side of the pending list. In most cases, these subscriptions will be updated and processed
automatically, once the bank file is imported. It is also possible to manually cancel or process the
pending subscriptions by using either the Delete or the Process subscriptions buttons respectively.
Unknown subscriptions can be recognized by the error icon, which indicates, that the subscription
cannot be finished until customer information has been specified. Once the required customer
information has been specified the error icon will change into a green check icon, indicating that the
subscription can now be finished. This is done by clicking the Process subscriptions button
7.4.2.3 ACTIVE SUBSCRIPTIONS
Once processed the pending subscription is moved to the list of Active subscriptions, marking that
the electronic mandate requirements for a withdrawal is met.
|Direct debit withdrawals 55
To remove an active mandate, simply click the Delete button in the grid’s top menu and confirm the
removal in the deletion prompt dialog.
The most common scenario is for the customer itself to terminate the subscription that allows withdrawals.
In that case, provided the bank can deliver the information, the customer is unsubscribed automatically
because of a bank response file
|Payment notifications 56
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.
8.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 5.3). 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.
8.2 POSTING JOURNAL
The posting journal is used to match and settle bank transactions against either payments from the
payment journal or open customer/vendor transactions and is opened from AMC Banking > Journals
> Posting journal.
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
|Payment notifications 57
Company The company, which the journal belongs to
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 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.
8.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 notifications 58
✓ 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 specific auto match classes. I.e.
it is possible to tamper with the individual match levels; hence, they can differ from the description above.
8.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 either Settlement on the Settlement tab or Payment on the
Payment tab.
Clicking Settlement will open a settlement page, in which the user, can settle the bank transaction
against open invoices in AX. The open invoices available depends on the individual bank transaction,
and e.g. depends on the account type and currency of the bank transaction.
|Payment notifications 59
Clicking Payment will also open a settlement-like page. Unlike the settlement pages, which allow
settling of open invoices directly, the payment page instead allow users to settle the bank transaction
against payment(s), that have been executed from the Banking module’s payment journal. In this
scenario, the payment works as an indirect link between the posting record and the open invoices
settled against the payment.
Posting journals, and thereby posting records, are usually created because of imported bank return
files, such as account statements or payment notification. Thus, a posting record is usually tied to a
specific bank account. The payments available for settlement are therefore limited to the payments,
which have been executed on the bank account of the posting record. Furthermore, the payments
are limited, based on the posting record’s currency and status, where only payments with status
Transferred, Received or Validated are included.
Once a payment’s status reaches Executed, the payment is posted, considered as processed and will
therefore no longer be available for settlement in the payment settlement page.
|Payment notifications 60
Usually a posted payment is also an Executed payment, but if bridge posting is activated, a posted payment
can have status Transferred. The payment settlement pages solely consider the status of the payment,
when filtering available payment. In this scenario, the users are therefore allowed to select the posted
payment, thereby completing the bridge account to bank account posting.
In both the regular settlement page as well as the payment settlement page, 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 receives invoice A + B
Invoice A
Invoice B
Customer pays invoice A + B
Invoice A
Invoice B
Customer receives invoice C
Invoice A
Invoice B
Invoice C
Customer mistakenly pays both invoice B + C
Invoice A
Invoice B
Invoice C
Payment exceeding expected amount
Invoice A
Invoice B
Invoice 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
8.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.
|Payment notifications 61
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 page allows modifying the expected cash disc easily by
using the designated cash disc fields in the bottom of the settlement page.
Depending on how the cash disc has been incorrectly utilized, there are different 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
8.2.4 ADDITIONAL FUNCTIONS
The posting journal has several functions, which can be used to ease the process, getting from import
to post. The functions are available from the Functions menu
|Payment notifications 62
The menu items have the following functions:
Menu item Function
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
8.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.
|Account statements 63
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 7).
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.
9.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 5.3). 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.
9.2 RECONCILIATION
To start reconciling the bank account(s), open the list of own bank account from AMC Banking >
Common > Own bank accounts.
|Account statements 64
The own bank account grid contains two fields furthest to the right, Last date and Reconciled. The
two fields provide a quick overview of the bank accounts, which 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 page.
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 page as can be opened from the bank account overview. In this case, though, the
reconciliation page will only include bank transactions related to the current selected account
statement.
|Account statements 65
The reconciliation page 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 page will open using the Unreconciled view. Two further view options exist, which can
be activated from the View menu.
- Unreconciled: Bank and ledger transactions, which have not yet been reconciled.
- Reconciled: Bank and ledger transactions, which have been reconciled.
- All: Both reconciled and unreconciled bank and ledger transactions.
9.2.1 AUTOMATIC RECONCILIATION
To start an automatic account reconciliation run, click Auto reconcile. This will open a small dialog
allowing the user to enter a few criteria, which decides the behavior of the automatic reconciliation.
|Account statements 66
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 OK to initiate the
reconciliation functionality. The automatic reconciliation will loop through the bank transaction
displayed in the page 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.
|Account statements 67
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.
9.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 Reconcile. 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 one reconciled
transaction would result in the need to unreconcile all other related transactions as well.
9.2.3 LEDGER PROPOSAL
When reconciling transactions manually, situations where the bank and ledger amount does not
match, is likely to occur.
|Account statements 68
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.
Clicking the “Proposal button will open the reconcile ledger proposal page.
|Account statements 69
When the user is satisfied with the ledger proposal, the proposal can be transferred to a ledger
journal by clicking Transfer to ledger. The transfer dialog allows the user to select a ledger Journal
name and has a Post option, which allows the user to automatically post the created ledger journal
The ledger part of the reconciliation page is showing data directly from standard ledger tables. Thus, transactions posted from the ledger proposal are available immediately in the reconciliation page.
9.3 REPORTS
The Banking module contains two reports to support the bank account reconciliation process, which
are available from the Print menu.
|Account statements 70
9.3.1 RECONCILIATION REPORT
To document the account reconciliation process, it is possible to print out a reconciliation report by
clicking the Print > Reconcile report in the own bank account list page.
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:
|Account statements 71
9.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.
|Appendix 72
APPENDIX
10.1 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
10.2 POSTING SCENARIOS
The exchange rate when importing status files (DEBMUL) for the different posting scenarios can be:
Own account
currency
Payment
currency
Posting MSD Posting CUR Exchange rate
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
10.3 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.
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
|Appendix 73
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.
Once OK 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, an infolog is returned,
and the user can download the demo file.
|Appendix 74
10.4 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 75
The module will pair the credit notes with the earliest payment, which exceeds the credit note’s amount.
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015800
31.01.2015-2.000
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015800
31.01.2015-2.000
Payment outside date range
Open transactions
Removing payments outside date range (...but keeping credit notes)
01.01.2015-500
08.01.20152.000
10.01.20151.500
10.01.2015-1.200
12.01.2015400
15.01.2015-500
31.01.2015-2.000
No payment large enough
Credit note accumulation:
08.01.2015300
10.01.20151.000
12.01.2015400
31.01.2015-2.000
Result:
01.01.2015-500
10.01.2015-1.200
15.01.2015-500
08.01.20152.000
10.01.20151.500
Credit note outside date range
Credit note outside date range