Finance Manager user guide

Solution Overview

Aritma Finance Manager addresses common challenges in managing bank-related processes in Microsoft Dynamics 365 Business Central by providing a secure, automated, and transparent integration between Business Central and the bank.

When Finance Manager is installed, three new areas become available in the Role Center or through search.

The page Finance Manager Operations is the main entry point of the solution and brings together all work related to payments, incoming transactions, and bank account reconciliation.

The Bank Transfers area supports the outgoing payment flow described in 1. Pay, including creating payments, tracking payment statuses throughout the process, and handling rejected payment files.

The Bank Transactions area displays all reporting received from the bank, related to both outgoing and incoming payments. This is where bank transactions are retrieved from the bank and posted in Business Central, either automatically or manually. It is described in 2. Posting.

The final area is 3. Bank Account Balance & Reconciliation. It shows the daily opening bank balance retrieved from the bank for each bank account in the solution, the bank account balance posted in the Business Central Bank Account module, and the daily difference between the opening balance and the bank account balance.

The same tiles and the Bank Account Balance part are also added to the top of the standard Business Manager Role Center, together with the navigation items Bank Transfers and Bank Transactions.

The tiles have the following meaning:

Getting Started

This chapter is intended for the administrator who connects Business Central to Aritma and the bank for the first time.

Prerequisites

Before you start the setup wizard, make sure that:

• Company Information → Registration No. is filled in. It is used to identify the company at Aritma.
• Every bank account you want to connect has Bank Account No., SWIFT Code and IBAN filled in on the Bank Account Card. Bank accounts that are missing any of these fields are not shown in the wizard.
• The user running the wizard has administrator rights in Business Central. The wizard registers the Microsoft Entra application Finance Manager Hub in Business Central.
• A person with signing authority for the company's bank accounts (a signatory) is available, either during the wizard or afterwards by e-mail.

Setup Wizard – Get started with Aritma

When Finance Manager has not been set up yet, a notification is shown on the Role Center:

"Finance Manager is now available! Start the setup wizard to connect your bank accounts and automate your payments and receipts."

Choose Start Setup Wizard in the notification. You can also start the wizard at any time from Finance Manager Setup → Finance Manager Setup action, or by searching for Get started with Aritma.

The wizard guides you through the following steps:

1. Welcome – choose Next.
2. Use Existing Environment – only shown if a tenant has already been configured, for example for another company in the same environment. Select the tenant and choose Use Existing Tenant, or choose Create New Tenant.
3. Create tenant – enter a Tenant Name, the main contact (e-mail and phone of the person responsible for your organization) and a technical contact (name, e-mail and phone). Choose Next to submit the request to Aritma.
4. Tenant Created – choose Finish. Aritma now approves the tenant. When it has been approved, a new notification is shown on the Role Center: "You are now ready to onboard your bank accounts." Choose Start Bank Account Onboarding to continue.
5. Before You Connect Your Bank – a reminder to check the prerequisites above.
6. Connect Bank Accounts to setup – select the bank accounts to connect. If a bank account is missing, check that it has Bank Account No., SWIFT Code and IBAN, that it is not already connected, and that the bank is supported by Aritma.
7. Authentication Handling – the bank connection must be authorised by a signatory with BankID. - Leave I will authenticate selected if the signatory is present. - Otherwise clear the checkbox and enter the Recipient (name, e-mail and phone of the signatory) and Sender details. The authentication links are then sent by e-mail.
8. Authenticate Bank Connections – choose the link for each bank (<BIC> – Authenticate with BankID) and complete the authentication. If only one bank is selected, the link opens directly. This step is skipped if the links were sent by e-mail. If you continue without completing the links, Aritma will follow up before the connection is activated.
9. You have finished the setup – choose the link for each bank (<BIC> – View instructions) to see what must be done on the bank's side before the connection is active.

Step 2 – Use Existing Environment:

Step 3 – Create tenant:

Step 6 – Connect Bank Accounts to setup:

Step 7 – Authentication Handling, with I will authenticate cleared:

After the Wizard

When the bank has activated the connection, Finance Manager links the bank's accounts to your Business Central bank accounts automatically, matching on bank account number and currency. Bank accounts in local currency are matched against Business Central bank accounts with a blank Currency Code.

If an account cannot be matched automatically, the page Match Bank Accounts opens. Select the corresponding Business Central bank account for each row and choose OK.

A background job checks the connection status once a day until all bank accounts are connected. You can also check the status manually from the Bank Accounts list with the action Get Consent Status.

When the bank accounts are connected, the Aritma Account Id field is filled in on the Bank Account Card (group Aritma Finance Manager).

Finally, review the job queue entries that were created when the app was installed and set the ones you want to use to Ready. See Job Queues.

1. Pay

Pay Overview

There are two ways to initiate payment proposals. Payment proposals can be created automatically by enabling Add to Suggestion when Posting on the Finance Manager Setup page, or they can be created manually.

When Add to Suggestion when Posting is enabled, a payment proposal is automatically generated when a purchase invoice is posted in Business Central.

To initiate payment proposals, or to review previously created payment proposals, go to Suggested under Bank Transfers on the Finance Manager Operations page:

The upper part of the page provides an overview of all created payment proposals grouped in batches. When a batch is selected, the lower part of the page displays the underlying invoices and credit memos included in the batch:

Create Payment Suggestion Manually

To create a payment proposal manually, select Suggest Bank Transfers. The same function can also be found by searching for Bank Transfer Suggestions.

The Bank Transfer Suggestions page opens. Start by entering a Last Due Date. All open entries with a due date up to and including this date are included.

The request page has the following options:

Further down the page, you can filter on No. and Currency Code for vendors, customers and employees. Once the filtering is complete, choose OK.

The payment date of each line is set as follows:

• The due date, if it is in the future; otherwise today's date.
• The payment discount date, if Include Payment Discount is selected and the discount can still be taken.
• The Requested Payment Date, if Override Due Date is selected.

The following entries are never included in a suggestion: entries that are On Hold, entries marked Exclude from Pmt. Practices, entries that have an Applies-to ID, entries that are already on a bank transfer, and entries on a rejected bank transfer until the rejection has been marked as handled.

The recipient bank account is taken from the Recipient Bank Account on the ledger entry, otherwise from the vendor's Preferred Bank Account Code. If neither is set, the vendor's only bank account is used, or the only bank account in the currency of the entry. If the vendor has several bank accounts that could be used, no bank account is selected and the bank transfer gets a validation error – set a Preferred Bank Account Code on the vendor to avoid this.

If problems are found during the suggestion, for example a missing bank account, you are asked whether you want to open the list of bank transfers with validation errors. See Validation Errors.

The payment proposal is created.

Create a Bank Transfer from a Ledger Entry

You can also create a suggestion for a single entry directly from Vendor Ledger Entries, Customer Ledger Entries or Employee Ledger Entries with the action Create Bank Transfer. A bank transfer with status Suggested is created for the selected entry.

The ledger entry pages also show the columns Payment Status and Exclude from Pmt. Practices.

Sending Bank Transfers

Once the payment proposal is complete, the next step is to send it to the bank for signing.

This can be done either automatically by setting up the job queue 72850696 – Sched. Bulk Payment, or manually from the Bank Transfer List opened from the Suggested tile. The Send Bank Transfers button contains two actions:

• Send Selected Bank Transfers – sends only the bank transfers you have selected.
• Send All Suggested Bank Transfers – sends all suggested bank transfers within the current filter.

Only bank transfers with status Suggested can be sent. You can also send a single bank transfer from the Bank Transfer card with Send to Bank.

Before a bank transfer is sent, each line is checked against its ledger entry. If the entry has been closed, or if the remaining amount no longer matches the amount on the line, sending is stopped with a message that shows the ledger amount and the bank transfer line amount. Run the suggestion again or correct the line before you send.

The action Payment Suggestions Lines opens a flat list of all suggested bank transfer lines with header information, which is useful for review or for exporting to Excel.

Validation Errors

Bank transfers are validated when they are suggested and before they are sent. If a problem is found, the bank transfer gets the status Validation Error and cannot be sent. These bank transfers are shown in the To Handle tile under Bank Transfers.

Each problem is listed on its own line in the Validation Error Log fact box on the Bank Transfer List and on the Bank Transfer card. Typical errors are:

Lines whose ledger entry is marked Exclude from Pmt. Practices are removed from the bank transfer during validation.

While a bank transfer has the status Validation Error, you can edit the Pay-to Bank Account, the Payment Date and the lines directly on the bank transfer. When you have corrected the master data, choose Validate Bank Transfers to validate the bank transfers again. Bank transfers without errors get the status Suggested. The job queue Validation Transfer can also do this automatically.

The Bank Transfer Details fact box shows the recipient's bank account details – Pay-to Bank Account Code, Currency Code, SWIFT Code, IBAN, Bank Branch No. and Bank Account No. – so you can check where a payment is going before it is sent.

Working with Bank Transfer Lines

The bank transfer lines show, among other things, Document Type, Document No., Payment Reference, Amount, Due Date and Regulatory reporting Code. The following columns are hidden by default and can be added with Personalize:

• Initial Due Date – the due date of the original posted invoice or credit memo, before any change on the ledger entry.
• Pmt. Discount Date – the last date for the payment discount. The date is shown in green when the payment discount has been applied to the line.
• Document Date.

To see the invoice behind a line, select the line and choose View Document (Ctrl + F6). The action is available when an incoming document with an attachment is linked to the ledger entry.

Payment Plans

A payment plan splits one suggested bank transfer line into several payments with different payment dates, for example when you agree with a vendor to pay an invoice in instalments.

1. Open a bank transfer with status Suggested, select the line and choose Payment Plan.
2. The Payment Plan page shows the creditor, payment reference and the original Amount. The first line is the original line.
3. Add lines with Amount and Payment Date for each instalment. Difference Amount shows how much remains to be distributed and must be 0.
4. If needed, change the Posting Description (default Payment Plan <Document Type> - <Document No.>).
5. Choose OK and confirm that you want to post the payment plan.

The bank transfer line is reduced to the first instalment, which is paid as normal. The remaining instalments are posted as new open ledger entries with the instalment's payment date as due date. They are included the next time a payment suggestion runs with a Last Due Date on or after that date (or immediately if Add to Suggestion when Posting is enabled). Payment plans are intended for vendor entries. No. Series Remittance must be set up in Finance Manager Setup.

Await Net Balance

When Merge Payment is set to Await Net Balance for Payment (globally or for a vendor in Advanced Setup), a vendor's invoices and credit memos are netted. If the credit memos are larger than or equal to the invoices, the whole group gets the status Await Net Balance and is not sent. These groups are shown in the Await Net Balance tile (the tile is only visible when the setting is made on Finance Manager Setup; otherwise filter the Bank Transfer List on Transfer Status).

Every time the payment suggestion runs, the groups are rebuilt from the vendor's open entries, so they are released automatically when new invoices make the net balance payable.

On a line in a group with status Await Net Balance you can:

• Set Invoice as Suggested – pays the selected invoice in a separate bank transfer without netting it against the credit memos. The vendor's remaining Await Net Balance group is removed and created again the next time the payment suggestion runs.
• Exclude from Payment Practices – removes the selected document from the payment process. The entry is marked Exclude from Pmt. Practices.

Bank Transfer Summary

To get a quick overview of liquidity, choose Payment Summary or press F7 on the Bank Transfer List or Bank Transfers to sign. The page is displayed per bank account and shows:

• Overdraft – only shown when an Overdraft amount is entered on the Bank Account Card.
• Balance in Bank – the latest balance received from the bank.
• Payments In Process – bank transfers sent to the bank but not yet completed.
• Payment Suggestions – suggested bank transfers.
• Net Amount – the sum of the above, which is what is available after the payments. Shown in red when it is negative.

By default only bank accounts with suggested or in-process bank transfers are shown. Choose View All Accounts to show all connected bank accounts, and Update (Ctrl + F5) to recalculate.

Exclude Transactions

If, for any reason, you want to exclude a specific vendor or a specific vendor ledger entry from payment suggestions, the solution respects the standard field Exclude from Pmt. Practices. This field is evaluated in the following places:

Vendor Card

Purchase Invoice

Vendor Ledger Entry

The field is also available on Customer Ledger Entries and Employee Ledger Entries, and on the transaction journal lines in Manual Accounting.

When you change Exclude from Pmt. Practices on a vendor or customer card, you are asked whether the change should also be applied to the existing ledger entries for that vendor or customer.

In addition, all entries that contain a value in the standard field On Hold are excluded.

If the company has previously used Swebase, any entries where the field VP Pack No. contains a value are also excluded.

Approval Process

Overview

Signing can be performed directly in Business Central, in Finance Manager, or as a combination where the first signature is completed in Business Central and the second in Finance Manager.

The description below shows the signing flow in Business Central. For the signing flow in Finance Manager, refer to the separate manual.

Approve Payments in Business Central

To approve payments in Business Central, go to Finance Manager Operations → Bank Transfers → To Approve:

The Bank Transfers to Sign page opens.

To sign a single payment or selected payments, select the payment(s) and choose Sign Selected. To sign all payments listed on the page, choose Sign All.

Only bank transfers with status To approve or Partially approved are signed. You can also sign a single bank transfer from the Bank Transfer card with Sign payment.

The signing status of each bank transfer is shown in the field Signing status on the Bank Transfer card: Not signed, Partly signed or Signing finalized.

When you select Sign, Aritma's approval page opens. Review the information and choose Approve Payment.

Select Mobile Phone (you will receive an SMS with a verification code on your phone) or Authenticator (you will receive a verification code in your Microsoft Authenticator app):

Enter the code and choose Continue:

Bank Transfers In Process

After the signing process is completed, the payment is set to In Process. The payment remains in this status until the bank executes the payment.

At this stage, the payment status is retrieved via job queue 72850697 – Bank Transfer Status Update and, when webhooks are set up, pushed automatically from the bank as soon as it changes. The frequency of the job queue is defined on the standard Job Queue Entry page. The status is displayed on the In Process page in the Bank Transfers list:

As well as on the Vendor Ledger Entries page:

It is also possible to manually trigger a status update by opening the bank transfer and selecting Actions → Update Status. To update all bank transfers at once, choose Update Payment Status on the Bank Transfer List or Bank Transfers to sign:

Transfer Status Values

The Transfer Status field can have the following values:

Recently Completed

The Recently Completed queue shows payments where the bank has executed the payment. The queue is filtered dynamically to display payments with a payment date up to one month back in time. The posting of the payment is completed when the bank reports the transaction in Bank Transactions (see 2. Posting).

Use the standard filters to display any other, older payments.

Rejected

Bank transfers that are not accepted by the bank – status Rejected by bank or Mixed Payment Status – are shown in the To Handle tile under Bank Transfers, together with cancelled bank transfers and bank transfers with validation errors. The tile is shown in red when the count is above zero. The reason for the rejection is shown in the Message field on the bank transfer and its lines.

If a bank transfer is rejected, you can handle it directly on the Bank Transfer page by selecting Set Rejection Handled. This allows you to create a new payment proposal for the rejected transfer.

Cancelling and Deleting Bank Transfers

A bank transfer that has been sent to the bank can be cancelled with Cancel Payment on the Bank Transfer card. A cancellation request is sent to the bank, and the status of the bank transfer is updated with the bank's response – normally Cancelled. Whether a payment can still be cancelled depends on the bank. Check the Transfer Status afterwards.

Bank transfers can only be deleted when the status is Suggested, Validation Error or Await Net Balance, and only if they have not been sent to the bank. A bank transfer that has already been sent cannot be deleted – cancel the payment instead. When a bank transfer is deleted, the entries become available for the next payment suggestion.

Inyett Detect Payment Control

If your company uses the Inyett Detect payment control service, Finance Manager can send the payment suggestions to Inyett for analysis before they are sent to the bank. The functionality is only visible when an API Key is entered in the Payment Control group on Finance Manager Setup.

On the Bank Transfer List, the Inyett Detect button contains:

• Send to Inyett – sends the suggested vendor and customer payments to Inyett Detect. Wait a minute while Inyett processes them.
• Show warnings – retrieves and shows the warnings from Inyett on the Inyett Detect warnings page. Choose Show warning on a line to open the details in Inyett Detect.
• Revoke sent task – withdraws the suggestion from Inyett, for example if you need to change it.

After the warnings have been retrieved, the column Warning status on the bank transfer lines shows whether there is a warning for the line. Use Show warnings on a line to see the warnings for that line only.

When a suggestion has been sent to Inyett, the bank transfers cannot be sent to the bank until the warnings have been retrieved with Show warnings. If Mandatory to get warnings from Inyett before creating the payment file is selected in setup, this always applies.

2. Posting

Bank Transactions – Overview

The Bank Transactions pages display all reporting received from the bank, covering both outgoing and incoming payments. Bank transactions are typically retrieved early in the morning via job queue 72850695 – Fetch Transactions and, if automatic posting is enabled, they are posted via job queue 72850694 – Bookkeeping.

It is possible to retrieve and post transactions manually. However, the most common approach is to automatically post all transactions that can be matched, and only work with the exceptions where the system is unable to find a matching entry in To Handle:

The To Handle view shows all transactions that have not been matched, or where an error occurred during posting, and the transaction gets Status: Open.

The Not Posted view shows all bank transactions that have not been posted. In a typical scenario, work is primarily performed from the To Handle view.

A bank transaction has the Status Open or Released, and the checkbox Posted shows whether it has been posted. Open is shown in red and means that the transaction needs to be handled. Use Release (Ctrl + F9) and Reopen to change the status manually.

On the Bank Transaction List, the posting actions are grouped under Post:

On the Bank Transaction card, the Post menu also contains Reverse Mark as Posted.

When a transaction is posted, the Transaction Id from the bank is used as External Document No. on the posted entries. On General Ledger Entries and Bank Account Ledger Entries you can drill down on External Document No. to open the bank transaction it came from.

How Automatic Matching Works

When bank transactions are imported, Finance Manager tries to find the right account for each line automatically.

Incoming payments are matched in this order:

1. Structured invoice reference – a reference from the bank that is an invoice or credit memo number for a customer ledger entry. If the entry is already closed, the line gets a message and no further matching is tried.
2. Payment reference and message – invoice numbers (also OCR/KID references with check digits) found in the payment reference or the free-text message. If several invoices are found, the line is split into one line per invoice.
3. Known payer – the payer's bank account or name from earlier payments, combined with an open entry with exactly the same amount.
4. Internal transfer between your own bank accounts that was initiated from Finance Manager.
5. Bookkeeping Rules.
6. Apply Bank Ledger Rules.

Outgoing payments that were created by Finance Manager carry a reference to the vendor, customer or employee ledger entry they were paid from, and are matched back to that entry. Other outgoing payments are matched with bookkeeping rules and apply bank ledger rules.

Lines that cannot be matched get a message, for example No match has been found for this transaction, and the transaction stays Open in To Handle.

To Handle

The To Handle view shows all transactions with the status Open.

This usually means that the transaction has not been fully matched against a ledger entry or a bookkeeping rule, and therefore requires manual handling. The reason is shown in red in the Message field.

The Transaction Details fact box shows the Account Name, Currency Code, the Remaining Amount of the matched invoice, and the Difference Amount between the paid amount and the remaining amount. This makes over- and underpayments easy to spot.

On the Transaction Details lines you can also:

• Choose View Document (Ctrl + F6) to open the invoice the line is matched to.
• Choose Read Entry Details Information to see exactly what the bank sent for the line. This information is available until the transaction is posted.
• Drill down on End-to-End Id on outgoing payments to open the ledger entry the payment was made from.

Manual Accounting

To help the system find a ledger entry, or to link the transaction to a G/L account or a bank account, select the line and choose Manual Accounting:

Here, you can link the transaction to a ledger entry or a G/L account by selecting the appropriate Account Type. You can also add a description, which is transferred to the general ledger entry, and apply dimensions if needed. The column Account Name shows the name of the selected account; drill down on it to open the account card.

If you want to link the transaction to a vendor ledger entry, for example, first select Account Type: Vendor and enter the vendor number in Account No.. Then link the specific ledger entry by entering the document number in Applies-to Doc. No..

By opening the information pane on the right-hand side, you can attach documents to the selected line, and they will be included in the general ledger entries. When done, choose OK:

Additional possibilities in Manual Accounting:

• Split a payment over several lines. Add one line per account or invoice. When you add a new line, the remaining amount is suggested automatically. The lines must add up to the transaction amount before you choose OK; otherwise you are asked whether you want to close the page and start over later.
• Look up the invoice. In Applies-to Doc. No., select the open entry. Account No., Currency Code and the remaining amount are filled in automatically. If a payment discount can still be taken on the booking date, it is deducted from the proposed amount.
• Foreign currency. The header shows Original Transaction Amount, Original Instructed Amount and the Exchange Rate used by the bank. You can change the Exchange Rate. On the lines, enter the Instructed Amount in the invoice currency and the Amount in the transaction currency is calculated.
• Projects. The columns Project No. and Project Task No. can be added with Personalize. Projects can only be used on lines with Account Type G/L Account.
• Exclude from Payment Practices can be set on customer, vendor and employee lines.
• Excel. Use File Handling → Export Journal Lines to Excel and Import Journal Lines from Excel to prepare many lines in Excel. Importing replaces the existing lines.

In the example below, an invoice in USD is paid from a SEK bank account. The Exchange Rate is used to calculate the SEK amount from the instructed USD amount.

Already Posted

If a bank transaction has already been posted earlier, either through another process or manually, it is possible to close the transaction in the bank module and remove it from the To Handle list without creating any new accounting entries.

The To Handle list is based on open Bank Account Ledger Entries. By selecting the already posted transaction in Applies-to Bank Document No. on the bank transaction header and choosing Mark as Posted, the related Bank Account Ledger Entry is closed.

Choosing … in Applies-to Bank Document No. opens Apply Bank Account Ledger Entries, which lists the open bank account ledger entries for the bank account. Select Apply Entry on one or more entries and adjust Amount to Apply if needed. Remaining Amount to Apply must be 0 (shown in green) before the transaction can be marked as posted. When several entries are applied, the field shows Multiple entries....

This action does not create any new general ledger entries and does not post the transaction again. It only closes the Bank Account Ledger Entry and marks the bank transaction as posted, removing it from the To Handle list.

If a transaction has been marked as posted by mistake, open the Bank Transaction card and choose Post → Reverse Mark as Posted. The bank account ledger entries are reopened and the transaction gets the status Open again.

Not Posted

The Not Posted view shows fully matched transactions that have not yet been posted. Posting is usually performed via an automatic job, but it is also possible to select Post in the upper part of the page.

In the example below, the transaction has been fully matched and can therefore be posted either manually or automatically. Here it is posted manually:

Manual Import of Transactions

To import transactions manually, go to the Bank Transaction List and select Import Transaction:

In From Date Time, enter the date and time from which transactions should be imported.

If a transaction has been imported incorrectly, or if you want to start over with a transaction you have been working on, select it and choose Reload transaction. The transaction is deleted and the bank account's transactions for that booking date are imported again from the bank. Any manual accounting on the transaction is lost. Posted transactions cannot be reloaded.

Not Posted transactions can be deleted by selecting one or more transactions and choosing Delete.

Preview Posting

Before you post a bank transaction, you can see exactly which entries will be created. Select the transaction and choose Post → Preview Posting (Ctrl + Alt + F9). The standard Business Central posting preview opens and shows the G/L, customer, vendor, bank account and VAT entries. Nothing is posted.

The transaction must be fully matched – all lines must have an account – before it can be previewed.

Post Internal Bank Transfer

A transfer between two of your own bank accounts is reported as two bank transactions: a payment from one account and a receipt into the other. To post them together:

1. In the Bank Transaction List, select both transactions.
2. Choose Post → Post Internal Bank Transfer and confirm.

The selection must contain exactly two transactions – one payment and one receipt – with the same booking date, and neither may be posted. Transfers between bank accounts in different currencies are supported, and any realised exchange rate gain or loss is posted automatically.

Bookkeeping Rules

If a specific text appears in the bank statement describing a transaction, or if there are known dates and expected amounts, it is possible to set up automatic posting rules.

Bookkeeping rules are created by navigating to the Bank Transactions page and selecting Bookkeeping Rules. A rule is applied when the message text of the transaction contains the text in Search Filter. Wildcards are not needed.

The rules below specify that transactions with the reference text "bankcost" or "bankkonstnad" are automatically posted to G/L account 6570.

Additional settings allow you to define Lowest Amount and Highest Amount, a day range within the month (From Day in Month and To Day in Month), and to assign dimensions, a specific Description, Gen. Posting Type and VAT posting groups. Project No. and Project Task No. can be added with Personalize for rules posting to a G/L account.

The Active field ensures that the bookkeeping rule is applied automatically when transactions are imported.

It is also possible to apply a bookkeeping rule manually to an unmatched transaction via Apply Bookkeeping Rule on the Transaction Details lines in the Bank Transaction List. Select several lines to apply the rule to all of them at once.

Select the relevant rule and confirm by choosing OK.

Apply Bank Ledger Rules

Some bank transactions correspond to entries that are already posted in Business Central, for example card settlements or payments posted from another system. Apply Bank Ledger Rules applies such transactions automatically to the matching open bank account ledger entry and, optionally, marks them as posted.

Open the page from the Bank Transaction List with Apply Bank Account Rules, or search for Apply Bank Ledger Rules. Each rule has:

A rule is only applied when exactly one open bank account ledger entry has the same amount and a posting date within the range. If there are several candidates, the transaction is left for you to handle.

Bank Transactions Report

To print a bank transaction as it was delivered by the bank – for example as documentation for an auditor – select the transaction in the Bank Transaction List and choose Report → Bank Transactions. The report shows account, sender or receiver, date, amount, booking reference and message for each line.

3. Bank Account Balance & Reconciliation

Account Balance & Reconciliation – Overview

All bank accounts that are part of the solution, including foreign currency accounts, are displayed in the Bank Account Balance area on the Finance Manager Operations page.

One of the key strengths of the solution is that there is no need to perform a traditional bank reconciliation. By following the Finance Manager processes as intended, you maintain real-time visibility into bank balances without requiring a separate reconciliation process.

The Bank Account field displays the bank account that is mapped to the standard Bank Accounts in Business Central.

The Balance Amount field shows the latest actual bank balance retrieved directly from the bank. This typically represents the previous day's closing balance and is updated nightly from the bank. If no activity occurs on the bank account on a given day, no update is fetched to the list.

Click the balance amount to open a log showing all balance retrievals from the bank:

Bank Account Balance shows the running balance of the bank account based on the standard Bank Account Ledger Entries in Business Central. Select the field to open the Bank Account Ledger Entries page.

Balance Difference displays the difference between the balance reported by the bank and the balance posted in the Bank Account module. It is shown in red when it is not zero. Selecting the amount opens the Bank Transaction List with the bank transactions for that bank account that are not yet posted.

The balances are shown as of the work date. To retrieve the latest balances from the bank immediately, choose Get Account Balances in the Bank Account Balance part. When webhooks are set up, balances are also updated automatically when the bank reports a change.

Bank Account Reconciliation Report

Even though a traditional bank reconciliation is not required, there may be situations where you need to print or generate a report showing that the bank account is reconciled, for example as documentation for an auditor. In such cases, a dedicated report is available.

To access the report, go to the Bank Transactions list:

In Date Filter, enter the period to reconcile, for example 010126..311226 (required). The opening balance is calculated as of the start of the period and the closing balance as of the end. Select Print Details to include the individual bank account ledger entries with a running balance. You can also filter on specific bank accounts.

For each bank account connected to Finance Manager, the report compares the balance in the bank, the balance of the bank account and the balance of the related G/L account. Below that, the Opening Balance and Closing Balance for the period are shown, and with Print Details each bank account ledger entry with its Posted Balance.

Standard Bank Account Reconciliation

If you still want to use the standard Business Central bank account reconciliation, the bank transactions from Finance Manager can be used as bank statement. On the Bank Acc. Reconciliation page, choose Get Bank Statement Transactions. All Finance Manager bank transactions up to the Statement Date that have not been imported before are added to the statement lines.

On Bank Account Ledger Entries, the action Close/Reopen Entry can be used to close or reopen selected entries manually. A closed entry is considered reconciled between Business Central and the bank.

Setup

Finance Manager Setup Page

Search for Finance Manager Setup to open the setup page.

General

Country-specific versions of Finance Manager can add fields to this group, for example Code Bank of Sweden in the Swedish version.

Aritma Integration Setup contains Subscription Name and Resource Group Id. These are filled in by the setup wizard.

Payment Control contains the settings for Inyett Detect: API Key, the language for warnings, whether Registration No. is mandatory, whether warnings must be retrieved before payments are sent, and whether suggestions are sent to Inyett automatically when they are created.

The page also has the following actions:

• Check Connection – tests the connection to Aritma.
• Finance Manager Setup – starts the setup wizard.
• Advanced Setup – see Advanced Setup.
• Go to Bank Accounts, Go to Job Queues and Go to Webhook Subscriptions.

Pay – Payment Merging Options

On the Finance Manager Setup page, the Merge Payment field has several options for grouping payments and credit memos. If the field is blank, Only Full Deduction per Payment Date is used.

Option 1: Only Full Deduction per Payment Date

The system checks whether the total amount of debit invoices per payment date exceeds the available credit memo amount.

• If yes: The credit memo is fully applied against the debit invoices.
• If no: The debit invoices are included in the payment proposal, while the credit memo remains in the ledger until future invoices allow full application.

Option 2: Await Net Balance for Payment (Recommended)

When this option is enabled, a monitoring queue called Await Net Balance for Payment is created.

• Invoices are placed in the queue until the vendor's net balance is positive (that is, there is an amount to be paid).
• Once a net balance exists, the invoices are merged into a single payment proposal.

The user can:

• Manually select debit invoices for payment.
• Exclude specific debit invoices and/or credit memos from the queue.

Option 3: Merge via Finance Manager Portal

All handling of debit and credit invoices, including merging, is performed in the Finance Manager Portal instead of directly in Business Central.

Option: No Merging – Payment per Transaction

No merging is performed.

• Each debit invoice is paid separately.
• One payment is created per individual transaction.

Option 4: Payments Only (No Credit Memos)

Only debit invoices are included in the payment proposal.

• Credit memos are not included in merging or payments.
• No application against credit memos is performed.

Advanced Setup

Payment merging options can be configured per vendor via Actions → Advanced Setup on the Finance Manager Setup page. This allows you to override the general setup for specific vendors when required.

Each line in Advanced Setup has a Main Category, a Sub Category, an Account Type and an Account No. There are two main categories:

For Receipt Transactions, choose Advanced Setup Filter to define which transactions the line applies to: select a text field on the transaction (for example the message text) and enter the text it must contain in Filter Text Contains.

The setup below illustrates an example where the general payment merging configuration is not applied to vendor 1000. This vendor follows a separate process for handling credit memos, which are therefore always excluded from the payment proposal.

The example below excludes incoming payments whose Remittance Reference contains REDOVISNING from automatic matching:

Bank Account Settings

The Bank Account Card has a group Aritma Finance Manager with the following fields:

The pay-from bank account for a payment is the connected bank account in the currency of the payment. If there are several, the one marked Use as Default for Currency is used.

Job Queues

Various job queues are used to set up automation between Finance Manager and Business Central. This section provides an overview of the job queues that can be configured and describes their purposes.

When Finance Manager is installed, the following job queue entries are created in each company. They are all created with the status On Hold. Review them and set the ones you want to use to Ready (open them with Go to Job Queues on Finance Manager Setup).

During onboarding, two additional job queue entries are created in the category ARIFMRDM: Aritma Onboarding Redeem Polling and Aritma Onboarding Consent Status Polling. They remove themselves when onboarding is completed.

72850695 – Fetch Transactions

The Fetch Transactions job is used to retrieve bank transactions from the bank. It is uncommon not to set up this job. It is typically run only once or a few times each night, as different banks make transactions available at different times. The job should run at least once before the start of the workday in the morning.

72850694 – Bookkeeping

Bookkeeping is used to automatically post the transactions retrieved by 72850695 – Fetch Transactions that have been matched to a ledger entry. The job is configured depending on the level of automation that is desired.

When this job is configured, manual posting should only be required for exceptions where a 100% match is not achieved. This job queue should preferably be scheduled to run a few minutes after 72850695 – Fetch Transactions to ensure that all transactions have been retrieved before posting begins.

72850718 – Mark As Posted

Mark As Posted marks bank transactions that have been applied to existing bank account ledger entries – manually or with Apply Bank Ledger Rules – as posted. Transactions that cannot be marked as posted get the status Open and an explanation in Message.

72850722 – Validation Transfer

Validation Transfer validates all bank transfers with the status Validation Error again, so that they get the status Suggested as soon as the master data has been corrected.

Bank Transfer Suggestions (report 72850676)

This job queue entry runs the payment suggestion automatically, with vendor payments included. Use it if you want new payment suggestions to be created without anyone running Suggest Bank Transfers manually.

72850697 – Bank Transfer Status Update

Bank Transfer Status Update is used to retrieve the transfer status of outgoing payments. This job should always be set up. The Transfer Status field is available on the Bank Transfer List and in the Vendor Ledger Entries.

When webhook subscriptions are set up, status changes are also pushed automatically from the bank, and this job serves as a fallback. If webhooks are not used, you can run the job more frequently to ensure that the correct status is reflected promptly.

72850696 – Sched. Bulk Payment

Sched. Bulk Payment is used depending on the desired level of automation for the outgoing payment process.

If Add to Suggestion when Posting is enabled in Finance Manager Setup and you want to avoid a manual step for sending payments for approval, this job queue can be configured to submit outgoing payments for approval in Finance Manager at the frequency specified in the job queue settings, prior to payment execution.

Webhook Subscriptions

Webhook subscriptions let the bank push changes to Business Central as soon as they happen, instead of Business Central asking the bank on a schedule. They are created by the setup wizard. Three subscriptions are used:

• Consent – changes in the connection status of the bank accounts.
• Payment – changes in the status of bank transfers and payment lines.
• Balance – changes in the bank account balance.

Open the page with Go to Webhook Subscriptions on Finance Manager Setup. The actions are:

• New Subscription – creates the subscriptions, for example if they have been deleted.
• Delete – deletes the selected subscriptions.
• Verify Grant Consent – checks that the Microsoft Entra consent for the integration is in place.

Permissions

Finance Manager includes two permission sets:

• ARIFM BASIC – read and write access to all Finance Manager data. Includes ARIFM EXECUTE.
• ARIFM EXECUTE – permission to run all Finance Manager functions.

ARIFM BASIC is included in the standard permission set D365 BASIC, so users with D365 BASIC have access to Finance Manager. Running the setup wizard requires administrator rights.

Release Notes

Release notes for the Aritma Finance Manager library for Microsoft Dynamics 365 Business Central, newest release first.

Each entry is written from the code changes in that release rather than from commit messages, and describes what changed for people using the app.

26.25 2026-10-13

This is a feature release. The main addition is Manual Payments: you can now create ad-hoc payments to any recipient and upload a salary pain file, without needing a ledger entry to pay against. The release also reworks onboarding and assisted setup, adds matching on payment reference, and fixes several matching and currency issues.

Manual payments

A new Manual Payment page lets you pay someone who has no open ledger entry. Open it with the new Process Payment action on Bank Account Balance or on the Bank Account Card.

Fill in the recipient and address, IBAN, SWIFT, bank branch, account number, a message (optionally structured), the amount, the currency and the payment date. Choose Save as template to keep the recipient for later, and use the lookup of saved recipients (Manual Payment Entries) to fill in the details next time.

Before anything is created, you are asked to confirm the amount. The payment is then created as a bank transfer with the new account type Manual Payment, and its end-to-end ID starts with "M" so it is easy to recognise.

Finance Manager checks the entry first: recipient name, message and amount are required, and the payment date cannot be in the past.

Upload a salary pain file

The Manual Payment page has a new Upload Salary Pain File action. Choose a pain XML file and Finance Manager reads it, shows you the total amount for confirmation, and then creates a manual payment entry for each payment in the file.

Bank signing page opens after sending

When you send bank transfers to the bank, from the Bank Transfer card, the Bank Transfer list or Send Selected Bank Transfers, the page set in Bank Signing URL on the setup page now opens, if you have filled it in. This takes you straight to where you sign and approve the payments.

Payment suggestion report and due date formula

The Bank Transfer List has a new Payment Suggestion Report action with a Group by due date option, so you can review suggested payments by the day they fall due.

The Transfer Suggestions report has a new Last Due Date Formula option, so you can set the last due date as a formula instead of a fixed date.

Balance check on the transfer summary

The Bank Transfer Summary now checks the available balance against a minimum balance. If sending would take the account below it, the check can stop the send, so you do not submit payments the account cannot cover.

Finance Manager in assisted setup

Finance Manager Setup is now registered in assisted setup under a new Finance Manager group, so you can find and start it from the standard Business Central assisted setup list.

Onboarding wizard handles missing bank accounts

The onboarding wizard has a new step, No Bank Accounts Configured. It is shown when no bank account is ready to be onboarded, or when all of them are already onboarded. The step has an Open Bank Accounts action that takes you to your bank accounts so you can add or correct them, instead of leaving you on an empty page.

Get Redeem from setup

Finance Manager Setup has a new Get Redeem action. If you do not have write access to Job Queue Entry, you now get a message pointing you to this action instead of an error.

Matching on payment reference

Bank transactions can now be matched on the payment reference. If a match is found against a closed customer ledger entry, you are told so with the message "There is a match against a closed customer ledger entry. Document No. %1", so you can see why it was not applied.

More validation of payment details

Bank transfer validation gives clearer messages in more cases:

• the SWIFT code is not valid
• the Bank Account No. or IBAN is missing
• the Bank Giro or Plus Giro is missing

In the Swedish version, when the SWE Base App is installed and a workflow is enabled, validation also checks that the vendor bank account is approved. If it is not, you see "The vendor bank account must be approved".

Translations

Finance Manager now has a full German (de-DE) translation. The Danish (da-DK), Finnish (fi-FI), Norwegian (nb-NO) and Swedish (sv-SE) translations have been updated with smaller changes.

Fixes

• Foreign-currency payments had the wrong Transaction Amount. The currency is now taken from the bank transaction header, and the amount uses the exchange rate from the bank's response.

• Receipt details were incomplete. Receipt transaction details now fill in Instructed Amount and Currency.

• Additional remittance text was overwritten. It is now appended to the existing text and limited to 250 characters, instead of replacing what was there.

• Payment approval could fail. The authorization request for the signing basket has been corrected.

• "Set Unmatched Transaction Open" used the wrong condition. The condition has been corrected so it applies to the right transactions.

• Document lookup could disturb the record being worked on. It now uses a temporary record.

• The creditor address was missing the building number. The building number is now included.

• The Main Category Setup page description could not be translated. It is now translatable.

• Empty instructional texts on the wizard could be edited. They are now locked.

26.24 2026-09-22

This release focuses on giving you more control before you post. You can now preview the accounting entries for a bank transaction before committing them, post transfers between your own bank accounts directly from the transaction list, and open the underlying invoice as a PDF without leaving the page. Bank transfer validation now works line by line, so a single excluded vendor no longer discards an entire transfer.

Preview posting before you commit

You can now review exactly which entries a bank transaction will create before you post it. Open a bank transaction and choose Preview Posting (or press Ctrl + Alt + F9) to see the general ledger, customer, vendor, bank and VAT entries that posting would produce. Nothing is written to your books until you post for real.

The transaction must be fully matched before you can preview it. If something is still unmatched you will be told to match it manually first, which makes the preview a useful completeness check in its own right.

The preview is available both from the bank transaction list and from the individual bank transaction page.

Post internal transfers between your own bank accounts

When you move money between two of your own bank accounts, the transfer shows up as two separate bank transactions — a payment from one account and a receipt into the other. Previously these had to be handled separately. You can now select both lines in the bank transaction list and choose Post Internal Bank Transfer to post them together as a single internal transfer.

Finance Manager checks that your selection makes sense before posting and tells you specifically what is wrong if not:

• exactly two transactions must be selected
• one must be a payment and the other a receipt
• both must have the same booking date
• neither may already be posted

Transfers between accounts in different currencies are supported. Finance Manager works out the exchange rate from the two transaction amounts and posts any realised exchange rate gain or loss automatically, so the transfer balances. If the entries do not balance, posting stops and reports the difference rather than leaving your books skewed.

Both bank account ledger entries are applied and marked as posted together.

Open the invoice behind a line

A View Document action (Ctrl + F6) has been added so you can see the source document for a line without navigating away. It is available on transaction detail lines and on bank transfer lines.

For payments to vendors and receipts from customers, this opens the PDF attached to the related incoming document. For receipts, it can also generate the posted sales document — invoice, credit memo, finance charge memo or reminder — as a PDF on the fly using your standard report selection. The action is only enabled when a document is actually available, so you are not left clicking something that does nothing.

Reverse an incorrect "Mark as Posted"

If you marked a bank transaction as posted by mistake, there is now a Reverse Mark as Posted action to undo it. Any error messages recorded against the transaction are cleared at the same time.

The posting actions on the bank transaction page have been grouped together under a Posting menu, so Post, Mark as Posted, Reverse Mark as Posted and Preview Posting now sit together instead of being spread across the ribbon.

Send only the bank transfers you select

The bank transfer list previously offered a single Send Bank Transfers action that sent everything suggested. That action is still there, now named Send All Suggested Bank Transfers, and it is joined by Send Selected Bank Transfers, which sends only the lines you have picked.

The two actions are grouped as a split button, so the full-send action is still one click away but is no longer the only option. Only transfers with status Suggested can be sent; anything else is rejected with a clear message.

Payment practice exclusions now follow the ledger entry

Bank transfer validation previously read the exclusion from the vendor record, so one excluded vendor affected the whole transfer. Validation now reads the exclusion from each individual ledger entry instead.

To keep entries in step with the party they belong to, changing Exclude from Pmt. Practices on a vendor or customer now prompts you to apply the change to that party's existing ledger entries as well, so you decide whether it takes effect retroactively.

When bank transfers are validated, excluded entries are dropped from the transfer rather than the whole transfer being discarded because of one excluded party. A transfer is only removed entirely if every line on it is excluded. The validation applies to both vendor and customer transfers; previously only vendors were checked.

Regulatory reporting codes no longer required in FI, DK, DE and GB

Validation of regulatory reporting codes on cross-border transfers is now skipped entirely for the Finnish, Danish, German and British application families, where the requirement does not apply. Transfers in those markets are no longer blocked by a missing reporting code.

Choose where exchange rates come from

Bank accounts have a new Exchange Rate Source field with three options: Calculated, Exchange Rate From Bank and Currency Factor From Bank.

Previously Finance Manager always took the exchange rate and unit currency from the bank's transaction data when it was present. If you set the source to Calculated, that data is now ignored and the rate is derived instead, which is useful when your bank's reported rates do not match the basis you want to post on. The other two options keep using the bank-supplied values. This affects both payment and receipt transactions.

Account for overdraft in the balance summary

Bank accounts have a new Overdraft field. Where an account has an overdraft limit, the bank transfer summary now adds it to the net available amount and shows it as its own line, so the figure you are working from reflects what you can actually spend rather than just the cleared balance.

The summary also gains a View All Accounts action. By default the summary shows only accounts with bank transfers currently in progress; this action widens it to every bank account.

Onboarding matches bank accounts more accurately

When connecting bank accounts during onboarding, Finance Manager now reads the IBAN and currency reported by the bank and uses the currency when matching against existing bank accounts in Business Central. Accounts in your local currency are matched against accounts with a blank currency code, following the standard Business Central convention. The IBAN is now shown during onboarding too.

Bank consent requests now identify accounts by IBAN rather than by bank account number, which is what banks expect, and accounts without an IBAN are excluded from onboarding. An account is also only added when its bank could actually be identified from the SWIFT code, so unrecognised banks no longer produce half-configured entries.

Onboarding also reuses an existing resource group if one is already set up, instead of always deriving one from the company registration number — so re-running onboarding no longer risks creating a parallel setup.

Bank transfer status is checked less aggressively

The Bank Transfer Status Update job queue entry previously ran every minute. It now runs every 720 minutes (twice a day) within its existing 06:00–18:00 window, substantially reducing background load and the number of calls made to your bank.

This applies to new installations. Existing job queue entries keep their current schedule, so adjust the interval manually if you want the new cadence.

Verify consent and reach webhook settings

A Verify Grant Consent action has been added so you can confirm that the Entra consent for your tenant, environment and company is in place, and get a clear answer back rather than discovering a consent problem later as a failed sync.

The Finance Manager Setup page now has a Go to Webhook Subscriptions action, so webhook subscriptions are reachable directly from setup.

Fixes

• Applying bank ledger entries could use the wrong sign. When applying entries, the amount to apply is now given the same sign as the entry it is applied to. Previously the raw remaining amount was used regardless of whether the entry was positive or negative, which could produce incorrectly signed applications.

• Matching bank ledger entries filtered the wrong record. Apply rules for transaction type and currency were being evaluated against the rule record instead of filtering the bank ledger entries, so rules did not narrow the candidates as intended. Receipt and payment rules now correctly restrict matching to positive and negative entries respectively.

• Matching a receipt could modify the record being iterated. Receipt matching now works on a copy of the transaction detail, preventing the loop from being disturbed partway through.

• Posting a bank transaction no longer closes the page. Post and Mark as Posted previously closed the bank transaction page, so you lost your place. The page now stays open.

• Deleting a webhook subscription could target the wrong environment. Deletion now only proceeds when the subscription's delivery URL matches the environment you are in — development URLs in sandboxes, production URLs in production — so a subscription belonging to the other environment cannot be removed by accident.

• Webhook errors appeared in Swedish regardless of language. Five hard-coded Swedish error messages ("Kunde inte skicka request.") have been replaced with a single English label.

• Banking role centre layout and labelling. The cue caption has been shortened from "Bank Transfers To Handle" to "To Handle", and the bank account balance part has been moved out of the cue group so it sits on its own rather than among the activity tiles.

• Bank messages were lost when a code or text was missing. When your bank returned a status message, Finance Manager built the message text assuming both a code and a message were present. If either was missing the message could be malformed. Each part is now read independently, so you still get whichever part the bank supplied.

• Copying a production environment to a sandbox left live webhook subscriptions behind. Webhook subscriptions are now cleared automatically when a company is copied into a sandbox, so a test environment cannot keep delivering against production subscriptions. Upgrade logic is also skipped in sandboxes.

• First Due Date on payment suggestions was not reset. The field has been removed from the request page and is now cleared each time the report runs, so a value left over from a previous run no longer silently narrows your suggestions.

Upgrade notes

This release adds fields and tables, so an upgrade is required. No data is removed and no existing field changes meaning.

New fields: Exchange Rate Source and Overdraft on Bank Account, IBAN on the onboarding bank account buffer, and an internal preview flag on General Journal Template.

Permissions for the new objects have been added to the ARIFM EXECUTE permission set. If you assign permissions through a custom set rather than the supplied one, add execute rights for the Internal Transfer Mgt., Preview Posting, Reverse Mark As Posted, View Document Mgt., Copy Environment Logic and Onboarding Consent JQ codeunits, and for the Payment Plan and Validation Error Log tables and pages.

If you rely on payment practice exclusions, note the behaviour change described above: bank transfer validation now reads the exclusion per ledger entry, and you are prompted to decide whether to apply it to existing entries when you change it on a vendor or customer.

Preview posting creates a temporary journal template and batch while it runs and deletes them afterwards. These are internal and are not intended to be edited.

Onboarding now requires bank accounts to have an IBAN. If accounts in your setup are missing one, populate it before connecting them.

For partners and extension developers: the ARIFM Transac. Posting Prev. codeunit is now marked obsolete (pending) in favour of ARIFM Preview Posting. If you reference it, migrate before it is removed. A new integration event, OnBeforeOnRun_CodeunitTransReverseMarkAsPosted, lets you intercept the reverse-mark-as-posted logic.

26.23 2026-08-25

A maintenance release containing build and tooling updates plus a small extensibility hook for partners. There are no functional changes for everyday users.

Upgrade notes

The OnAfterInitPaymentPlanGenJnlLine_CodeunitTransactionPosting method in the internal event handler was missing its [IntegrationEvent] attribute, so partner extensions could not actually subscribe to it. It is now a real integration event and can be subscribed to in order to adjust the journal lines created when a payment plan is posted.

26.22 2026-08-24

This is a large release centred on payments. The headline addition is payment plans, which let you split a single invoice into several instalments and post them directly from the bank transfer. Payment validation has been rebuilt so that every problem with a transfer is listed individually in a new side panel instead of being squeezed into one combined message, and transfers are now blocked from being sent when the amount no longer matches the underlying ledger entry. Account balances update automatically when your bank reports a change, and the onboarding wizard has been reworked and simplified.

Payment plans

You can now split a suggested bank transfer line into several payments. On a bank transfer line with status Suggested, a new Payment Plan action opens a worksheet showing the creditor, the payment reference and the original amount. Add lines with their own amounts and payment dates, and the worksheet shows a running difference between the line amount and the sum of your plan lines. You cannot leave the worksheet until the two match, and the original source line cannot be deleted.

When you confirm, the instalments are posted to the ledger and applied against the original entry, and the bank transfer line is updated with the remaining amount so only the first instalment goes to the bank now. Each posted line gets a description that defaults to "Payment Plan \<Document Type> - \<Document No.>", which you can change before posting. Payment plans are supported for vendor, customer and employee entries.

Validation errors shown as a list

Bank transfer validation no longer concatenates problems into a single message field. Every transfer now has its own validation error log, shown in a new fact box on both the bank transfer list and the bank transfer card, with each error on its own line and highlighted. Where before a missing bank account and an invalid SWIFT code would be merged into one string, you now see them separately and can work through them one at a time. The error log is cleared and rebuilt each time the transfer is revalidated, and is removed when the transfer is deleted.

Validation itself is also more thorough:

• Missing account details are reported as either "Bank Account No. or IBAN must be specified for the bank account" or "Bank Giro No. or Plus Giro No. must be specified for the bank account", rather than one generic message.
• A missing bank account record no longer stops the rest of the validation from running — previously a missing customer or employee bank account could cause a hard error instead of a validation message.
• SWIFT codes are validated only when present; a blank SWIFT code is no longer flagged.
• Cross-border transfers are now checked for a regulatory reporting code. If the paying bank account and the creditor are in different countries and any line is missing a code, validation fails with a message telling you to fill in the code on the line and update the pay-to bank account. The Regulatory Reporting Code field is now visible on the transfer lines so you can correct it there.

Payments are blocked when amounts drift

When you send a transfer to the bank, each line is now checked against its ledger entry before anything leaves Business Central. If the entry has been closed, or the remaining amount no longer matches the transfer line amount, you get an explicit error naming the entry, the ledger amount and the transfer line amount, instead of the payment going out with a stale figure. This check applies to vendor, customer and employee entries, and takes any applied payment discount into account.

Related to this, transfer lines now keep themselves in step with the ledger. If an open vendor entry changes while the transfer line is still only Suggested, the line amount is updated to the new remaining amount. If the entry is closed, a Suggested line is removed altogether, and the transfer header is deleted when its last line disappears. The same cleanup happens when you exclude a document from payment practices. You can now also delete a bank transfer that is in Await Net Balance status.

Creditor addresses taken from the bank account

Addresses sent to the bank now prefer the address on the vendor's or customer's bank account when one is filled in, falling back to the address on the vendor or customer card otherwise. If the primary address line is blank, the second address line is used. This applies to vendors, customers, employees and bank accounts, and means payments carry the address the bank actually expects.

Automatic balance updates and onboarding changes

Bank account balances are now refreshed automatically when your bank reports a balance change, via a new balance notification subscription that is set up during onboarding and added to existing installations on upgrade. The balance comparison on the bank account balance page now compares against entries up to and including the working date rather than the previous day.

The setup wizard has been reworked. The terminology changed from "workspace" to "tenant" throughout, the instructional text is considerably shorter, and phone numbers can now be entered for both the main contact and the technical contact. The technical contact name and email are now mandatory. The wizard no longer asks you to complete Entra admin consent in the browser during setup. The authentication step now explains that a signatory must complete each bank link, and that Aritma will follow up before activation if they are not completed. Bank instruction links now point at the production site when you are in a production environment.

Two new ways to check bank connection status are available. A Get Consent Status action on the bank account list refreshes consent status for all connected accounts on demand, and after completing the wizard a daily background job does the same automatically until every connected account has been activated, then removes itself. On the role centre, once your subscription is set up but no bank accounts are connected yet, you now get a notification with a Start Bank Account Onboarding action.

Other improvements

Bank transfer lines now carry the document date from the underlying ledger entry, available on the transfer line page and in the bank transfer data query.

When posting the balancing bank account entry for a transaction, the description is now taken from the transaction detail line where that is unambiguous, falling back to the bank's additional information. Previously the additional information was always used. Mixed transactions that combine G/L and subledger details are left alone.

A Bank Signing URL field has been added to Finance Manager Setup. When filled in, bank signing redirects you back to that address after approving payments in your bank, instead of the generic Business Central landing page.

Fixes

• Bank transfer fact box showed stale details. The fact box did not clear its fields between records, so when you moved to a transfer whose bank account had no SWIFT code, IBAN or similar, you could still see the values from the previously selected transfer. The fields are now cleared first.
• Transfers already handled as rejected were re-polled. The background status update job now skips transfers whose rejection has already been handled.
• Transactions could stay stuck as not completely fetched. Transactions that had details fetched but had never been posted were not marked as completely fetched and so were repeatedly re-processed. They are now corrected automatically.
• Account numbers with separators broke onboarding. Bank account numbers and company registration numbers are now stripped of dots, dashes and spaces before being sent for onboarding, so formatted numbers no longer cause the registration to fail.
• Connection test could pass on a stale token. Testing the connection from Finance Manager Setup now always requests a fresh token, so it reflects the current state of the connection rather than a cached one.
• Background jobs retried too long after failing. The retry limit for the Finance Manager background jobs was reduced from 60 attempts to 5, so a persistent problem surfaces far sooner instead of being retried for hours.

26.21 2026-07-09

This release corrects the amounts shown on transaction details for customer and employee payments, changes when a transfer is put on hold to await a net balance, and clarifies two confusing bank status names.

Clearer bank statuses

Two transfer statuses had captions that did not describe what the bank was actually reporting, and one of them was duplicated word for word. The status previously shown as "Awaiting banks acceptance" is now Accepted technical validation, meaning the bank has accepted the technical validation of the payment. The status previously shown as "Awaiting banks acceptance." is now simply Pending.

Fixes

• Transaction detail amounts were wrong for customers and employees, and ignored the actual transfer amount. When matching a bank transaction detail back to a ledger entry, the amount was only filled in for vendor entries, and it always used the full remaining amount on the entry. Customer and employee entries are now handled as well, and the amount is taken from the matching bank transfer line where one exists, so partial payments show the amount that was actually sent rather than the full outstanding balance. The remaining amount on the ledger entry is still used as a fallback.
• Transfers were sometimes incorrectly put into Await Net Balance. The decision to put a vendor transfer on hold pending a net balance was made before all lines, including watched invoices, had been added. The check now runs on the completed transfer, so a transfer is only held when its total is actually positive.
• Error message about duplicate advanced setups listed a field that is not part of the check. The Danish, Finnish, Norwegian and Swedish translations mentioned a recipient account number that the uniqueness check does not include. The message now matches the English original.

26.20 2026-07-02

A fix release addressing missing detail lines on outgoing payment transactions.

Fixes

• Payment transaction details were silently skipped. When fetching details for an outgoing payment, the app checked whether any transaction detail already existed for that transaction and, if so, stopped without adding anything. This meant a transaction that had been partly filled in earlier never received its remaining detail lines. The check has been removed, so details are now written whenever the bank returns them.

26.19 2026-06-29

A fix release addressing missing detail lines on incoming payment transactions.

Fixes

• Receipt transaction details were silently skipped. As with outgoing payments, fetching details for an incoming payment stopped early if any transaction detail already existed for that transaction, leaving the remaining detail lines unwritten. Details are now written whenever the bank returns them.

26.18 2026-06-24

A small corrective release that stops already-posted bank transactions from being picked up again when transaction lines are fetched.

Fixes

• Posted bank transactions are no longer re-processed when fetching transaction details. When the app filled in the detail lines for transactions that had not yet been completely fetched, it also included transactions you had already posted, which could cause unnecessary work and repeated processing of closed items. Posted transactions are now excluded, and any older posted transactions still flagged as incompletely fetched are marked as complete automatically the first time you fetch after upgrading.

26.17 2026-06-16

This release reworks how bank transactions are brought into Business Central so that fetching is more robust, and it cleans out a number of long-deprecated settings and objects. It also corrects the document reference written on customer payment suggestions.

More reliable transaction import

Previously, each bank transaction had its detail lines fetched immediately as the transaction header was created. If anything interrupted that process part way through — a timeout, a connection problem, an error on one transaction — you could be left with transactions that had no detail lines and no easy way to complete them.

Fetching is now split into two stages. Transaction headers are read from the bank first, then detail lines are filled in for every transaction that is not yet marked as completely fetched. Each transaction is committed as it completes, so an interruption no longer loses the work already done, and the next fetch simply picks up where the previous one stopped. The app also now refuses to create duplicate detail lines for a transaction that already has them.

A transaction that ends up with no detail lines at all is now left with the status Open rather than being treated as fully processed, so it stays visible for you to deal with.

Cleanup of deprecated setup fields

Two setup fields that had been hidden and marked for removal for several releases are now gone for good: Include Credit Memos on the Finance Manager setup (its behaviour is covered by the Merge Payment options) and the old Tenant field (replaced by Subscription Name). The obsolete Global Tenant list has also been removed; environment configuration lives entirely in Global Environment now.

Fixes

• Customer payment suggestions now carry the correct document reference. The external document number on a suggested customer transfer was being filled with the ledger entry's external document number, which did not always identify the entry in your own system. It now uses the document number instead, making it easier to recognise the entry the payment belongs to.

Upgrade notes

Several integration events that were deprecated in version 24.5 have now been removed, along with the codeunits that only existed to host them. If you have a customisation subscribing to those events, move it to the replacement events before upgrading.

26.16 2026-06-04

A small release that smooths out webhook setup.

Fixes

• Setting up webhook subscriptions no longer fails when the required app registration already exists. Creating a new subscription now ensures the Entra application the integration needs is in place first, and the setup step exits quietly if that application has already been registered instead of attempting to add it again.

26.15 2026-06-02

This release gives you direct control over webhook subscriptions and improves bank account selection on vendor payment suggestions.

Managing webhook subscriptions

The Webhook Subscriptions list is no longer a read-only view that you edit by hand. You can now create the consent and payment status subscriptions in one step with a New Subscription action, and remove one or several selected subscriptions with a Delete action. Direct editing of the list has been disabled, since the subscriptions are maintained on the service side.

Fixes

• Vendor payments now pick a bank account matching the invoice currency. When a vendor had several bank accounts and no preferred bank account set, the app gave up and skipped the suggestion. It now narrows the vendor's bank accounts to those in the currency of the entry being paid, so vendors with one account per currency get a suggestion instead of being passed over.

26.14 2026-05-28

This release introduces a guided setup experience for connecting your organisation and bank accounts to Aritma, and adds push-based status updates so payment and consent changes arrive without you having to ask for them.

Guided setup for new companies

A setup wizard now walks you through getting started. It explains what will happen, lets you either create a new workspace for your organisation or pick an existing one, and collects the main contact (who becomes the workspace owner and receives an invite by email) and an optional technical contact.

The wizard then reminds you of the prerequisites your bank accounts need in Business Central — account number, IBAN and SWIFT code — and presents the accounts that qualify so you can choose which ones to connect. Where an account reported by the bank cannot be matched automatically to a Business Central bank account, a matching screen lets you pair them up by hand rather than failing silently.

The final steps cover bank authentication. You can either authenticate each bank connection yourself with BankID using the links shown in the wizard, or enter recipient and sender details so the authentication links are sent to whoever will perform the signing. When everything is submitted, the wizard shows per-bank instructions for the remaining steps on the bank's side.

If Finance Manager has not been configured yet, a notification appears on the Finance Manager role centre with a button that opens the wizard directly. You can also start the wizard any time from a new Finance Manager Setup action on the Finance Manager setup page.

Bank connection status on the bank account

Bank accounts now carry the consent that authorises Finance Manager to read them, along with the current consent status — created, started, authorised, expired, revoked, awaiting approval or failed. This is what lets the system tell you that a bank connection has lapsed rather than simply returning no data.

Payment and consent updates arrive automatically

Until now, the status of a payment only changed when something in Business Central went and asked the bank. The app can now receive pushed updates instead. When the bank reports that a bulk payment, an individual payment line or a bank consent has changed state, that status is written straight to the corresponding transfer, transfer line or bank account.

A Webhook Subscriptions page shows which subscriptions exist and which event types each one covers.

Fixes

• Error messages from the bank no longer break processing when they are incomplete. When the bank returned a status message that was missing a category, code or text, reading it could fail outright. Partial messages are now handled gracefully and the status update completes.
• Long values from the service no longer cause errors. Identifiers, links, names and similar values returned by the service are now truncated to fit the fields they are stored in instead of raising an error when they are longer than expected.
• Two error messages that appeared in Swedish regardless of your language are now translatable.

26.13 2026-05-22

This release brings project accounting into bank transaction handling, adds an Excel round-trip for transaction journal lines, gives you a printable view of a bank transaction as the bank delivered it, and considerably reworks how payments are applied to ledger entries.

Projects on bank transactions

You can now assign a project and project task to bank transaction lines, to transaction journal lines and to bookkeeping rules. Entering a project task pulls in its global dimensions and, where no description has been entered, its description. On a transaction journal line the project's currency is applied as well.

When a bookkeeping rule with a project is matched, the project and task flow through to the transaction line, and when the transaction is posted the resulting general journal line is created as a billable project line with a quantity of one. Projects are only allowed on lines posting to a G/L account. The project fields are hidden by default on the relevant pages — switch them on through personalisation if you work with projects.

Advanced setup now covers incoming payments

The advanced setup has been extended beyond merge-payment behaviour with a new Receipt Transactions category offering two options: Exclude from matching and Do not split by structured remittance information. The first stops selected incoming transactions from being matched automatically; the second keeps a transaction as a single line instead of splitting it into one line per structured remittance reference.

These options are driven by a new Advanced Setup Filter, reachable from the advanced setup line. There you choose a text or code field on the incoming transaction and the text it must contain for the rule to apply, so you can target, for example, transactions whose remittance text contains a particular reference. Filters are removed automatically when the setup line they belong to is deleted.

The uniqueness check on advanced setup lines now also takes the sub category into account, so you can set up more than one sub category for the same account, and the account number is only required where the chosen sub category actually needs one.

Bank transactions report

A new Bank Transactions report shows a bank transaction and its detail lines as the bank delivered them — account, sender or receiver, date, amount, booking reference and the message or remittance reference. The report carries a note making clear that it is a visualisation of the data Business Central received, and that the original accounting entry is in the file also linked to the transaction. Run it from the bank transaction list.

Original bank data kept with each transaction line

Incoming transaction lines now retain the raw entry details received from the bank. A new Entry Details Information field in the transaction detail fact box shows this content formatted for reading, and a Read Entry Details Information action displays the same thing in a message. This is useful when you need to see exactly what the bank sent, down to fields the app does not display. The stored data is cleared automatically when the transaction is posted.

Import and export journal lines through Excel

Transaction journal lines can now be exported to Excel and imported back. The export produces a sheet with account type and number, description, currency, instructed amount, amount, applies-to document type and number, posting type, VAT posting groups, the payment practices exclusion flag and all eight dimension codes. Importing replaces the lines for the transaction detail you are working on with the contents of the sheet, validating each value as it goes.

Reload a transaction from the bank

A Reload transaction action on the bank transaction list removes an unposted bank transaction and fetches it again from the bank for the same booking date. Use it when a transaction came in wrong or you want to start over on a transaction you have been editing. Posted transactions cannot be reloaded.

How payments are applied

Payments to vendors and customers are now applied using an application ID with an explicit amount to apply, rather than by pointing at a document type and number. This handles the case where several entries share a document number, and it makes the amount being applied explicit. The description on an automatically matched payment line now shows the document type, document number and ledger entry number, making it obvious which entry was picked.

Fixes

• Payment statuses on customer, vendor and employee ledger entries no longer show the wrong account type's status. The payment status shown on a ledger entry was looked up only by entry number, so an entry could display a status belonging to a different account type that happened to share that number. The lookup now also matches on the account type.
• Matching a payment to a customer or employee entry no longer stores a vendor entry number. When an incoming payment was matched to a customer or employee ledger entry, the reference written back to the transaction line was built from a vendor entry number instead of the matched entry. The correct entry number is now used.
• Transactions no longer match against your own bank accounts in the wrong direction. Internal transfer matching looked at both the debtor and creditor account regardless of whether the transaction was money in or money out. Incoming transactions are now matched on the sending account and outgoing transactions on the receiving account, and internal transfers are only recognised when the remittance text carries the app's own transfer marker — so ordinary customer and vendor payments are no longer mistaken for internal transfers.
• Bank transfer summary totals are now converted to the bank account's currency. Transfers in a foreign currency were added to the summary at face value, inflating or understating the total. Amounts are now converted using the exchange rate for the payment date. Transfers with the status received are also included in the committed total.
• Rejected payment lines now show why they were rejected. When a payment line comes back rejected, the app now fetches the detailed status for that line and records the bank's reason codes and messages on it.
• Employee payments now use the message to recipient as the payment reference. Employee transfer lines took their payment reference from a field that is generally empty for employee entries, leaving the payment without a reference. The message to recipient is used instead.
• Vendor payment suggestions no longer stop at the first entry that cannot be paid. When creating suggestions for a vendor, an entry that could not proceed would end the run for that vendor, skipping the remaining open entries. Each entry is now evaluated on its own.
• Deleting a bank transfer gives a correct explanation. The message shown when a transfer cannot be deleted now states that only transfers with the status Suggested or Validation Error can be removed, which is what the rule has always been.
• The internal bank transfer description is no longer overwritten with a fixed text.

26.12 2026-04-30

This release focuses on getting payment problems in front of you before the bank rejects them, and on making the app's background jobs set themselves up correctly. Bank account details on payment suggestions are now checked more thoroughly, a suggestion run no longer stops dead when one vendor is missing bank details, and the transaction journal shows the name of the account you are posting to.

Stronger checks on payment details

Payment suggestions and transfers are now validated against the SWIFT/BIC code on the recipient's bank account. If the code is not a valid SWIFT code, the transfer is set to Validation Error with a message naming the offending code, and the transfer cannot be sent to the bank. Previously an invalid code was passed on and the payment could be rejected later by the bank.

Missing bank account information is also handled better. Previously, if a vendor had no bank account at all, or had several bank accounts without a preferred one selected, the whole payment suggestion run stopped with an error and you had to fix the vendor before you could get any suggestions. Now the run continues, and the affected transfer is marked with Validation Error and the message that bank account information is missing, so you can see all problems at once and fix them from the transfer list.

Validation messages are now combined, so a transfer that has several problems lists all of them rather than only the first.

Vendors that are marked as excluded from payment practices no longer end up in payment suggestions — their suggested transfers are removed during validation.

Revalidating transfers

Validate Bank Transfers is now a promoted action on the bank transfer list, so you can re-run validation on transfers you have just corrected without digging through the menu. A background job is also available that periodically revalidates all transfers sitting in Validation Error, so transfers correct themselves once the underlying master data is fixed.

Account name in the transaction journal

The transaction journal lines now show the name of the account next to the account number, for vendors, customers, G/L accounts, bank accounts, fixed assets and employees. You can click the name to open the corresponding card.

Currency information from the bank

For transactions in foreign currency, the unit currency reported by the bank is now stored on the transaction and on its detail lines, and the exchange rate is now also picked up on incoming payments, not just outgoing ones.

Fixes

• Instructed amount currency was read from the wrong place. When the bank reported both an instructed amount and a transaction amount, the currency code on the instructed amount could be taken from the wrong part of the bank's response, leaving it blank or wrong. The amounts and currencies are now read from the correct fields in all transaction types.
• Transactions were wrongly flagged as not fully matched. Creating journal lines for a transaction could immediately set that transaction back to Open with a "not fully matched" message. That check no longer runs at that point.
• Suggestion runs could hang when scheduled. When the payment suggestion report found validation errors it asked whether you wanted to open the transfer list. When the report ran unattended as a background job there was nobody to answer. The question is now only asked when a user is present.

Upgrade notes

Installing this version now creates the full set of background job queue entries for the app — status updates, fetching transactions, bookkeeping, mark as posted, scheduled bulk payment, transfer validation and the bank transfer suggestions report — with recommended intervals and run windows. All entries are created with status On Hold, so review them and set the ones you want to Ready. Any existing job queue entries for these objects are replaced.

A new extension point has been added for partners that need to adjust how customer ledger entries are filtered when direct debit suggestions are created.

26.11 2026-04-19

A round of corrections to the bookkeeping rules, payment discounts in the transaction journal, and handling of internal transfers between your own bank accounts.

Internal bank transfers are now labelled for the bank

When you move funds between two of your own bank accounts, the payment is now sent to the bank with the standard internal-transfer purpose code and a description identifying it as an internal transfer of funds. This helps the bank classify the payment correctly and makes it easier to recognise on your statement.

Payment discounts when matching in the transaction journal

When you pick a customer or vendor ledger entry on a transaction journal line, the amount proposed now takes any available payment discount into account. If the discount date has not passed as of the booking date of the bank transaction, the proposed amount is the remaining amount less the remaining discount; otherwise the full remaining amount is proposed as before.

Fixes

• Bookkeeping and apply rules ignored their first and last day. Rules limited by day in month used an exclusive comparison, so a rule set to apply from day 1 to day 5 only applied on days 2 to 4, and a rule for a single day never applied at all. The range is now inclusive at both ends.
• Transfers stuck in Validation Error could not be deleted. Only transfers with status Suggested could be removed. You can now delete transfers with status Validation Error as well.
• Error when matching a transfer of funds with a long remittance text. Looking up the internal fund transfer behind a transaction failed with a length error when the remittance text from the bank was longer than expected. The text is now truncated safely before lookup.
• Account type was lost when inserting a journal line. Inserting a new transaction journal line above or below an existing one did not carry over the account type from the line it was inserted from.
• Swedish translation. A missing full stop in the Swedish text for the "Awaiting bank's acceptance" status.

Upgrade notes

Two new extension points are available for partners: one that lets a partner take over how payment status is retrieved for a bank transfer, and one that is raised before a customer bank transfer suggestion line is inserted.

26.10 2026-04-01

This is a large release for anyone who pays vendors that also send credit memos. How credit memos are netted against invoices is no longer a single on/off switch — you now choose a payment merge strategy, either for the whole company or per vendor. Payment discount handling in the suggestion run has also been reworked so that invoices with a discount are proposed on the discount date rather than being missed.

Choose how credit memos are merged into payments

The Finance Manager Setup page has a new Merge Payment field that replaces the old Include Credit Memos checkbox. You pick the option that matches how you work:

• Only full deduction per payment date — a credit memo is only deducted when the invoices for that payment date fully cover it. This matches the previous behaviour.
• Await net balance for payment — if credit memos exceed the invoices, the whole group is held back instead of being paid, and waits for future invoices to balance it out.
• Merge via Finance Manager portal — invoices and credit memos are passed on and the netting is handled in Finance Manager.
• No merging — payment per transaction — every invoice becomes its own payment.
• Payments only (no credit memos) — credit memos are left out of the suggestion entirely.

A new Advanced Setup page, reachable from Finance Manager Setup, lets you override the company-wide choice for individual vendors. Each line links an account to one of the merge options, and each combination of account and category can only be set up once.

Transfers waiting for a net balance

Payment groups that are being held back get the new status Await Net Balance. A dedicated tile on the Finance Manager role centre and activities page shows how many transfers are waiting, so they do not disappear from view. The tile is only shown when you have selected the await net balance option.

On a held transfer line you can act on an individual invoice: Set Invoice as Suggested releases it into a normal payment suggestion, and Exclude from Payment Practices takes it out of the payment process entirely after a confirmation.

Each time you run the payment suggestion, held transfers for the vendor are rebuilt from the current ledger situation, so the held amounts always reflect open invoices and credit memos as they are today.

Payment discounts in the suggestion run

Invoices that carry a payment discount are now treated on their own terms. When you include payment discounts, an invoice whose discount date falls within the period you selected is proposed for payment on the discount date, even if the due date is later — previously such invoices could fall outside the due-date range and be skipped. The discount is only deducted when the proposed payment date actually falls on or before the discount date, so you no longer see a discount deducted from a payment that is too late to earn it.

Transfer lines carry a new Payment Discount Applied marker and an optional Pmt. Discount Date column, which you can add to the line view. The date is highlighted when a discount has been applied to that line.

Smaller improvements

The Include Credit Memos option has been removed from the payment suggestion request page; the merge strategy now decides this. Error messages on transaction detail lines are shown in red so they stand out. The client ID and subscription ID are now visible on the global environment page, which makes it easier to confirm which subscription an environment is connected to.

Fixes

• Split transaction detail lines inherited the wrong values. When a transaction detail was split onto a new line, the amount and the remittance type, reference and text were copied from the original line. The new line now starts blank for these fields.

Upgrade notes

The Include Credit Memos setting is marked for removal and is no longer shown. If you relied on it, set Merge Payment instead. Vendors with no explicit merge setting fall back to Only full deduction per payment date, which matches the previous behaviour. Merge options are currently supported for vendors only.

26.9 2026-03-25

A corrective release around sending payments to the bank. Several operations that loop over bank transfers were skipping records, and the status of a transfer immediately after sending is now set correctly.

Bank transfers waiting for attention stand out

Bank transfers waiting for your attention are now highlighted in red on the Finance Manager role centre and activities page whenever the count is above zero, so outstanding work stands out at a glance.

Fixes

• Not all selected transfers were sent to the bank. When you sent several suggested transfers at once, processing one transfer disturbed the list being worked through, so some transfers were silently skipped. Each transfer is now processed independently and the whole selection is sent.
• Scheduled status updates skipped transfers. The same problem affected the background job that refreshes payment status from the bank, so some transfers kept a stale status. All transfers with a payment reference are now refreshed.
• Status after sending was unreliable. After a payment was accepted by the bank, the app immediately asked the bank for the status again, which could fail or return nothing useful. The transfer and its lines are now set directly to "received by the bank" and updated from the bank on the next status refresh.
• Unclear error when the bank rejected a payment. The raw response from the bank was shown on its own, which could be mistaken for an application message. Rejections are now clearly presented as an error with the bank's response quoted.

26.8 2026-03-23

This release protects you from sending the same payment to the bank twice, makes the bank balance comparison on the account balance overview correct, and lets you apply a bookkeeping rule to several transaction lines at once.

No more duplicate payments after an interrupted send

When a payment is accepted by the bank, the bank's confirmation is now stored on the transfer before anything else happens. If the session is interrupted part-way through — a timeout, a lost connection, an error while updating the transfer — sending the transfer again picks up where it left off using the stored confirmation instead of creating a second payment at the bank. Once the transfer has been fully updated, the stored confirmation is cleared.

As a safeguard, a transfer that has already been created at the bank can no longer be deleted. If you try, you are told to cancel the payment instead. Payment references received from the bank also cannot be overwritten by a second send.

Bank balance compared against the right day

The bank account balance overview previously compared the balance reported by the bank against your full bank account ledger, including entries posted today. Since the bank reports its balance as of the end of the previous day, the comparison was misleading. The ledger side is now calculated up to the previous day, so the difference you see is a real difference.

Apply a bookkeeping rule to several lines

On the transaction detail lines you can now select several lines and apply a bookkeeping rule to all of them in one go. Previously the rule was only applied to the line the cursor was on.

Fixes

• Account balances were fetched from the wrong date. When you had more than one bank account connected, the "fetch balances from" date was taken from the first account and reused for all the others, so some accounts were queried from the wrong point in time. Each account now uses its own last known balance date.
• Messages from the bank were overwritten or lost. Messages returned with a payment replaced each other, and long messages could overflow. Messages are now appended, and only as long as they fit.
• Transfer lines kept a stale status. When the bank's reply covered the whole transfer rather than individual payments, the lines underneath were not updated. They now follow the status of the transfer.
• Matched transactions stayed open. When a transaction detail was matched to a bank ledger entry by rule, the transaction itself stayed in status Open. It is now released.

26.7 2026-03-16

A small corrective release for approving payments at the bank.

Fixes

• Partially approved payments were left out of the approval request. When a payment group had already been partly signed, those payments were not included when you approved payments, so they stayed partly signed. Payments that are partially approved are now sent for approval together with the ones that are only received by the bank.
• Approving with nothing to approve. If no payments qualified for approval, an empty request was still sent to the bank. The app now simply does nothing.

Upgrade notes

This release also contains an update of the build and tooling files, with no effect on functionality.

26.6 2026-03-14

This release reworks how currency rounding is handled when posting bank transactions, introduces signing status tracking at the individual payment line level, and tightens the payment-sending flow. Several of the changes affect day-to-day posting, so read the upgrade notes before updating.

Automatic rounding correction when posting

Previously, if a bank transaction in a foreign currency did not balance to the last decimal after conversion to your local currency, posting either silently adjusted the bank line or stopped with an error telling you the difference was over the rounding precision. Now, when the remaining difference is small enough to be explained by rounding across the posted lines, the system posts a separate correction line to the rounding accounts configured on the currency, described as "Rounding correction for" followed by the currency code. You no longer have to intervene in those cases, and the correction is visible as its own ledger entry instead of being hidden inside the bank line.

Document numbering on posted bank transactions

Posted bank transactions now always take their document number from the remittance number series. Previously, if no number series was set up, the system fell back to using the bank's transaction ID (truncated to 20 characters) as the document number, which produced unreadable and inconsistent document numbers. The remittance number series is now required, and posting stops with a clear message if it is missing.

Signing status per payment line

Bank transfer lines now carry their own signing status, shown alongside the transfer status. When you create a signing basket, the basket is now built from the payment IDs of the individual lines that the bank has actually received, rather than from the transfer header alone. Status updates returned by the bank are matched back to the correct line by payment ID, so a transfer containing several payments that the bank handled differently now shows an accurate picture per line instead of stamping every line with the header's status.

Related to this, the transfer status previously labelled "Partially rejected" is now called Mixed Payment Status, which better describes the situation: some payments in the bundle succeeded and others did not, and you need to look at the lines to see which.

Payment control check before sending

When you send a bank transfer to the bank, the system now checks your Inyett Detect payment control state first, according to your setup. The confirmation message that previously appeared ("Payment sent successfully") has been removed — it was shown before the bank had confirmed anything, which was misleading. You now see the real status on the transfer instead. Cancelling a payment still confirms, and the message now names the payment ID that was cancelled.

Payment suggestions sent to Inyett Detect are now limited to vendor and customer lines, matching what the service supports.

Fixes

• Payments in foreign currency were missing a currency on the debtor account. The account you pay from is now always sent to the bank with its currency code (falling back to your local currency when the bank account has none), which avoids rejections from banks that require it.
• Posting a transaction with a zero transaction amount could fail with a division error. The exchange-rate calculation is now skipped when there is nothing to divide by.
• Duplicate payment suggestions for customers and employees. The check for previously rejected transfer lines only looked at vendor lines, so rejected customer and employee payments were not recognised. It now checks the correct account type.
• Charge Amount on a bank transaction could not be corrected. The field is now editable.
• Fetching transactions could fail on an internal consistency check. Transactions are now written correctly even when details arrive in more than one step.

Upgrade notes

The No. Series Remittance field in Finance Manager Setup is now mandatory for posting. Make sure it is filled in before posting bank transactions after the upgrade.

26.5 2026-02-27

This release adds full currency support to the transaction journal, so you can account for an incoming or outgoing payment in the currency it was actually invoiced in, and fixes several currency conversion problems when posting.

Currency in the transaction journal

When you do manual accounting on a bank transaction, the journal now works with two amounts. The header shows the transaction currency, the instructed currency and the exchange rate the bank applied — and the exchange rate is editable, so you can correct it when the bank's rate does not match what you need to post. On the lines there is now an Instructed Amount with its own Currency Code alongside the transaction amount.

In practice this means you enter the amount in the invoice currency and the system calculates the transaction-currency amount for you using the header's exchange rate. When you pick a document to apply to, the line now takes the currency and remaining amount directly from that customer, vendor or employee ledger entry, so applying a EUR invoice from a SEK bank account no longer requires manual conversion. The balancing line created for the remainder of a transaction also picks up the correct currency.

More reliable posting across currencies

Posting now handles the case where the transaction currency, the instructed currency and your local currency are all different — previously the conversion in that situation produced wrong amounts or an unwanted currency factor. Lines with a zero amount are no longer posted at all, and the balancing bank line now takes the transaction's own currency when that differs from local currency.

Rounding behaviour changed as well: where the difference between the posted lines and the transaction total previously had to be exactly one cent to be absorbed, the difference is now compared against the actual rounding precision of the currency. If it is larger than that, posting stops with a message telling you the exact difference so you can review the transaction before posting.

Fixes

• Rejected bundles showed the wrong status on every line. When a bank reported a transfer as partially rejected, all lines were stamped with the header status. Each line now gets its own status fetched from the bank.
• Bank transfer list refreshed unnecessarily when opened, which could discard unsaved edits.

Upgrade notes

The extension points used by companion and customer extensions have been reorganised. All integration events now live in a single internal event handler object, and the previous events in the individual objects are marked obsolete. Existing subscriptions keep working for now, but should be moved to the new events. The previous payment handler and get-transactions objects are also marked obsolete for the same reason.

26.4 2026-02-14

This release makes transaction retrieval complete when a bank returns large result sets, reworks when and how payment suggestions report validation problems, and extends payment practices reporting to customers and employees.

All transactions are now retrieved, not just the first page

When a bank returns a long list of transactions, or a transaction with many detail rows, the response is split into pages. Previously only the first page was read, so transactions and detail lines could be silently missing. The system now follows the bank's "next page" links until everything has been retrieved. This applies both when fetching transactions for an account and when fetching the details of a single transaction, including the JSON download.

Clearer validation of payment suggestions

Validation of bank details has moved to a single consistent step that runs after the suggestion has been built. The practical differences are:

• A transfer that previously stayed flagged as a validation error even after you fixed the bank account is now re-validated and returns to Suggested, with its message cleared.
• Transfer lines now get the same status as their header, so a transfer in error state no longer shows lines claiming to be ready.
• The prompt offering to open the list of failed transfers now appears once at the end of the run, and only when this run actually produced errors. Previously it could appear repeatedly, and could appear because of old errors from a previous run.
• A suggestion in error state is no longer silently grouped together with a valid one for the same vendor, customer or employee.

Payment practices on customer and employee entries

The Exclude from Payment Practices flag now carries through the whole chain. You can set it on a transaction journal line (only for customer, vendor and employee lines — the system blocks it elsewhere), and it is carried to the transaction detail and onto the posted ledger entry. Customer ledger entries also pick up the exclusion setting from the customer card when nothing more specific is set, and employee ledger entries now carry the flag from the journal line.

Due dates on payment suggestions

Payment suggestions for customers and employees no longer propose a payment date in the past. If the due date has already passed, today's date is used instead — this already applied to vendor payments and is now consistent across all three.

A new Initial Due Date column is available (hidden by default) on bank transfer lines. It shows the due date from the original posted invoice or credit memo, so you can see what the due date was before it was changed on the ledger entry.

Fixes

• Applied bank transactions were incorrectly flagged as "not fully matched". A transaction that you had applied to a bank account ledger entry still got a message asking you to match it manually. Applied transactions are now left alone.
• Fetching transactions could stop with an error when a bank returned an end-to-end identification that was not a number.

26.3 2026-02-10

A small corrective release.

Fixes

• Bank transfer statuses were not being refreshed in the background. A malformed filter in the scheduled status-update job meant that transfers which should have been checked against the bank were skipped. Statuses now update as expected.
• Transfers accepted by the bank were left looking as if they still needed signing. When the bank reported a payment as accepted for settlement or accepted technically, the signing status is now set to Finalized along with the transfer status.

26.2 2026-02-06

This release introduces rules for automatically applying bank transactions to open bank account ledger entries, replaces the tenant-based connection setup with a subscription-based one, and makes validation errors on payment suggestions correctable without starting over.

Rules for applying bank transactions automatically

A new Apply Bank Ledger Rules page lets you define rules that recognise recurring bank transactions and apply them to the matching open bank account ledger entry without any manual work. Each rule has a search filter matched against the transaction's remittance text, and can be narrowed by transaction type (payment or receipt), currency, a range of days within the month, and a posting date formula that widens or narrows the date window around the transaction's booking date. A rule only applies when exactly one open entry matches on amount and date, so an ambiguous situation is always left for you to resolve.

If Mark as Posted is enabled on the rule, the transaction is also marked as posted automatically. Rules are evaluated as part of the normal matching process for both incoming and outgoing transactions, and are reachable from the Bank Transaction list and card.

Alongside this, there is now a Mark as Posted Batch action that processes all released, unposted, applied transactions in one go. The single Mark as Posted action now runs through the same mechanism. Posting a transaction that is applied to a bank document is now blocked with an explanatory message — applied transactions should be marked as posted, not posted again.

Subscription-based connection setup

The connection to the Aritma service is now configured against a named subscription rather than a tenant. Finance Manager Setup has a new Subscription Name field, and the underlying settings (tenant ID, client ID, subscription ID, environment scope) are maintained on a new Global Environment page. Your existing settings are migrated automatically on upgrade.

Correcting payment suggestions that failed validation

Transfers that fail validation because the recipient has no usable bank account details are now easier to deal with. The pay-to bank account, payment date and transfer lines are editable while a transfer is in Validation Error state, so you can correct the details in place. A new Validate Bank Transfers action re-runs validation on the transfers in view, moving the ones you have fixed back to Suggested. The message explaining the problem is now highlighted in the list so it is easy to spot.

The prompt offering to open the list of failed transfers now appears once when the whole suggestion run is finished, rather than after each vendor, customer and employee section.

Reconciliation report and activity overview

The bank account reconciliation report now takes an opening balance into account: it uses the start of your date filter as the opening date and shows the opening balance as its own column, so the report reconciles over a period instead of only to a date. You can also filter the report by bank account number.

On the Finance Manager role centre, the Bank Transfers To Handle tile now counts everything that genuinely needs attention — rejected, mixed status, cancelled and validation errors that have not been marked as handled. The separate Rejected tile has been hidden, since it is now covered by that count.

Most Finance Manager pages now have teaching tips explaining what the page is for.

Fixes

• Fetching transactions re-downloaded from the wrong date. The starting point is now taken from the last posted transaction on the account rather than the last transaction of any kind, so already-fetched but unposted transactions no longer push the window forward and cause gaps. A date you enter manually is also no longer carried over to the next bank account in the run.
• Sending a customer refund to the bank could fail or use the wrong account. The customer bank account was looked up with only one key, so it could not be found. It now resolves correctly.
• Payment dates in the past. A vendor payment whose due date has already passed is now suggested with today's date instead of the overdue date.
• Payment details with no reference block were skipped, so lines were missing from the transaction. They are now created from the available detail.
• A transfer that failed validation could not be sent, but gave no indication why. It is now flagged with a validation error and an explanatory message instead of silently producing an incomplete request.

Other improvements

From the General Ledger Entries page you can now drill down on the External Document No. to open the bank transaction it came from. The Bank Transfers to Sign page has gained the bank transfer details FactBox showing the recipient's account details.

26.1 2026-01-24

This release adds the ability to apply bank transactions directly against open bank account ledger entries, improves automatic matching of incoming payments, and brings currency handling and the transaction journal closer to how Business Central journals normally behave.

Applying bank transactions to bank account ledger entries

You can now apply a bank transaction to one or more open bank account ledger entries. Choosing the assist edit on Applies-to Bank Doc. No. opens a worksheet showing the open entries for the bank account, with the total amount to apply and a running remaining amount at the top. Tick the entries you want and adjust the amount to apply per entry; the system prevents you from applying more than an entry's remaining amount. When several entries are applied, the field shows "Multiple entries...". On a posted transaction the same action opens a read-only view of what was applied.

Marking a transaction as posted now settles each applied entry individually: the remaining amount is reduced by the applied amount, and the entry is only closed when nothing remains. Marking as posted is refused if the total applied amount does not equal the transaction amount, or if applying would push an entry's remaining amount below zero — so a partially applied transaction can no longer be closed by mistake.

Better matching of incoming payments

Matching of incoming payments against open customer invoices has been improved in two ways. The remittance reference is now searched together with the remittance text, so references the bank supplies in a separate field are no longer ignored. And the system now builds a picture of your document numbering from your open customer ledger entries — prefixes, number lengths and the ranges in use — and uses it to recognise document numbers in free-text remittance information, including numbers written without their prefix. For SCOR-type references, trailing check digits are also tried, so a reference that carries extra digits still finds the right invoice.

Transaction journal

When you pick a document to apply to on a transaction journal line, the line now fills in the account number, the remaining amount and the currency from that ledger entry, instead of leaving you to type them. Changing the account on a line now clears a stale application rather than leaving it pointing at the wrong document. Shortcut dimensions 3 to 8 are now available on the journal lines, and VAT amount and shortcut dimensions carry over from the transaction detail when the journal is created.

A transaction whose original amount is zero no longer blocks you with a balance warning when there is nothing to balance.

Fixes

• Currency factor was applied even when there was no conversion, which could distort posted amounts. It is now only set when the rate actually differs from one.
• Bank charges were posted in the wrong currency when the bank account was in a foreign currency. The charge now follows the currency being posted.
• Transactions that did not balance by one cent after currency conversion are now adjusted automatically on the bank line instead of failing.
• Update Payment Status was unavailable on the Bank Transfers to Sign page. The action is now visible and promoted.
• The bank account on a suggested transfer could not be changed. It is now editable while the transfer is still Suggested.
• Debtor and creditor account numbers could be truncated to the length of the IBAN field instead of their own.
• The status-update background job had no interval set, so it did not run on a schedule. It now runs every five minutes.

Other improvements

The bank transfer list now shows a FactBox with the recipient's bank account details — account code, currency, SWIFT, IBAN, bank branch and account number — so you can check where a payment is going without opening the transfer. The transaction detail and transaction journal line FactBoxes show the account name, currency, remaining amount and the difference between the instructed amount and what remains, making over- and underpayments immediately visible.

26.0 2025-12-29

Aritma Finance Manager is the first release of Aritma's open banking extension for Business Central. It connects your Business Central bank accounts to your banks through the Aritma service so that you can retrieve bank transactions, account balances and payment statuses directly in Business Central, and send outgoing payments to the bank without exporting and uploading files.

Incoming transactions and automatic accounting. Transactions are fetched from the connected bank accounts, either on demand or by a scheduled job, and appear as bank transactions with their full detail lines, including remittance information, creditor and debtor names and account numbers, currencies and instructed amounts. A matching engine then tries to account for each detail line automatically: incoming payments are matched against open customer invoices and credit memos using structured references and free-text remittance information; outgoing payments are matched back to the vendor, customer or employee ledger entry they were sent from; and transfers between your own bank accounts are recognised and paired up. Anything the engine cannot resolve is flagged with a message so you can handle it manually. You can also define bookkeeping rules that assign an account, posting groups and dimensions to recurring transactions based on a search text, an amount range and the day of the month.

Where a transaction needs manual work — for example, one payment covering several invoices — the transaction journal lets you split the detail line across several lines with their own accounts, applications, VAT posting groups and dimensions, with the original amount shown so you can see what still needs to be allocated. Transactions are released and then posted to the general ledger, settling the customer, vendor, employee, G/L and bank account entries, handling bank charges and payment tolerance against the accounts you configure in Finance Manager Setup, and closing the corresponding bank account ledger entry.

Outgoing payments. You can generate payment suggestions for vendors, customers and employees over a date range, choosing whether to include credit memos, invoices, payment discounts and employee debt, and whether to override due dates with a single payment date. Suggestions become bank transfers with lines per document, which you send to the bank, sign through a signing basket, and then track as the bank reports back — received, pending, accepted, settled, rejected or cancelled — with a background job updating the statuses and a dedicated page listing the transfers waiting to be signed. Rejected transfers can be marked as handled once dealt with. For Swedish customers, payment suggestions can be sent to the Inyett Detect payment control service before being released, and the warnings it returns are shown per line.

Balances, reconciliation and overview. Bank account balances are fetched from the bank and shown next to the Business Central balance, with the difference highlighted and drillable. A bank account reconciliation report compares the bank balance, the bank account ledger and the corresponding G/L account for a period. A Finance Manager role centre and activity cues give an overview of suggested, to-approve, in-process, recently completed and rejected transfers, and of bank transactions that still need handling or posting.

Payment practices. Entries can be excluded from payment practices reporting, with the exclusion flowing from the purchase document through the journal to the posted ledger entry.

The app ships with Danish, Finnish, Norwegian and Swedish translations in addition to English.