Release 2025, November

The following enhancements and improvements to existing functionality have been released this month.

2025-11-28

Accounting rules issue with invoices and credit notes containing both positive and negative lines

Invoices and credit notes containing both positive and negative lines were incorrectly posted to accounting when supplier accounting rules were applied. This caused batch imbalances and incorrect ledger postings. Now, the voucher accounting rule distribution logic has been modified to accurately perform debit/credit swapping when required.

Downloading documents from AutoInvoice

In the latest update to the AutoInvoice Download Service, two significant improvements have been made to enhance data accuracy and integrity:

  • The Download from last created date logic has been refined to only process documents that have a value in the External document ID field in the Accounting document table. This will prevent download time gaps caused by documents that are manually imported or imported through third-party integrations.
  • A nightly routine has been implemented to automatically download any missed invoices from the previous day. This routine is scheduled between 1:00 AM and 5:00 AM (UTC),

Pre-registered incoming invoices sent for approval seem unprocessed

Invoices that were fully processed and sent for approval continued to appear in Unprocessed tab with status 0, even though supplier transactions were correctly updated. This issue affected customers using pre-registration of incoming invoices. The status handling has now been corrected, and the document will be set to status 2 - Sent to accounting and the invoices appear on the correct tab (Processed) and with the correct status (2 - Sent to accounting ).

Interim account not suggested when creating cost lines

The interim account is no longer suggested when creating cost lines. The interim account will be used only for pre-registration and the update supplier transaction process.

2025-11-25

Filtering in joined table not recognised

When creating a printout, for example an invoice, from a layout that contains a filter in the joined table, the printout was generated regardless of the filtering. This has been solved.

Loading of table prevented due to access restrictions

If access isn't granted to a joined table column, the table won't be displayed, but a message explains that the table can't be loaded because of missing access to the specific column relation.

2025-11-17

Incorrect VAT calculation

Previously, for invoices with partly non-deductible VAT (Cost %), there could be errors in calculations and unbalanced batches, and incorrect rounding lines were added. This has been solved.

Account set not added correctly on purchase order lines

When the enabling Firstly get account set from stock in the Order processing in the Company information table, the Account set is fetched from the Warehouse table for orders and order lines. However, when purchase orders were generated from sales orders and sales order lines, this setting was ignored and the account set wasn't added correctly on the purchase order lines. This has been solved.

2025-11-14

Capital asset hierarchies

You can now arrange capital assets in a hierarchy, using the Main cap. asset no. field in the Capital asset table. This makes it possible to group on main units and add summary lines for the main units in capital asset reports.

Leading zeros in Danish bank account numbers

The issue with handling leading zeros in Danish bank account numbers has been resolved. With this improvement, bank registration numbers remain as 4-digit values, and account numbers are automatically completed with leading zeros to reach the standard 10-digit length. This ensures that all bank account details are correctly formatted and validated, meeting Danish requirements for both bank registration and account numbers.

In addition, the system now detects a bank account mismatch when the number of digits on the supplier record differs from the digits interpreted from the invoice. When this happens, the system automatically adds the missing leading zeros to the invoice bank account so that users can update the supplier’s bank information early in the process. Although this mismatch temporarily stops the document flow, it is intentional: it helps prevent incorrect payments by ensuring that bank account data is corrected before the payment process continues.

2025-11-13

Deletion of users when transferring companies

Previously, when transferring companies to a different customer, users were deleted from the previous customer, since all roles were revoked. This has been solved, and users will no longer be deleted from the previous customer.

2025-11-11

Empty credit account type in voucher lines for incoming payments

To reduce manual handling of incoming payments without a corresponding open entry, for example payments from the authorities, the Credit account type field now remains empty if no value for Credit account is filled in after import of incoming payments, and no match have been executed. This is according to the general behaviour in Business NXT: the value for Credit account type is only set as a result of an entry for Credit account, according to the predefined values for the different series in the Account no. series table.

Mapping of invoices containing a FIK account

When creating or identifying a supplier from a Danish PEPPOL BIS 3 invoice containing a FIK account, the PayeeFinancialAccount was previously mapped to Bank account instead of Postal giro. This has been solved.

2025-11-10

Document routing improvements

Several improvements have been made to support document routing in the approval workflow:

Support for Swedish bankgiro and Swedish plusgiro

Swedish payment means is identified based on the Financial Institution Branch ID. If a Swedish bankgiro or Swedish plusgiro is detected, the value from PayeeFinancialAccountID is fetched. This value is cleared from spaces and special characters, and a dash is added before the last four digits, to be compared to the Bank account field in the Associate table. If a mismatch is detected, the document processing is stopped, and the document gets the bank account mismatch status. In case a new supplier is created, the Bank account field in the Associate table is set in the correct format, including the dash.

Issues with processing documents in spite of matching bank accounts

Under certain circumstances, documents with matching bank accounts were detected as bank account mismatches and were stopped in the Unprocessed tab, because all bank account types ( BBAN/IBAN/POSTGIRO) were expected to match in order to pass the validation. This has now been updated, and if one of the bank account types match on the supplier information with the same bank account type, then the bank account mismatch check is considered passed.
Note:
In a situation where the supplier has, for example BBAN and the invoice has IBAN, this will still be considered a bank account mismatch. You are encouraged to update and set up your supplier records with correct information, since that is used for the payments.

Display of supplier of duplicate invoices

Previously, when a duplicate invoice was detected, the interpreted supplier wasn't saved in the document, which could lead to confusion since it was difficult to understand why the duplicate was detected. This has been solved. The duplicate invoice is detected as before, based on the supplier and invoice number, but the interpreted supplier is saved in the document, and gives meaning to the error message.

Issue when sending batch invoice with total discount to AutoInvoice

When sending a batch invoice with total discount to AutoInvoice, the tax amount used in the XML would be incorrect if the document delivery method AutoInvoice wasn't set, because the discount was deducted on the order line Amount. This has been corrected, and the Amount is now shown without total discount deducted.

2025-11-06

Missing voucher numbers when posting incoming payments

The locking mechanism when creating voucher lines for incoming payments has been improved.

2025-11-05

Cost correction postings during purchase order line invoice receival

When invoice receival was performed on purchase order line level, postings with cost corrections weren't created; this was only done when the invoice receival occurred at the purchase order head (Order table). This has been solved.

Erroneous calculation of VAT amount

Even if Do not calculate VAT amount had been selected in the VAT code processing field in the VAT code table, a value was calculated for the VAT difference field. This has been solved.

Group sums in calculated columns

When a calculated column formula that contained a minus value group, sums were showing incorrect results. Now the calculation with minus values is done correctly for group sums also.

Updated document routing in approval workflow

Previously, a bank account mismatch during approval didn't prevent a document from being sent to the For processing tab. Now, a document with a bank account mismatch will stay under the Unprocessed tab, and marked Processing Error – Bank Account Mismatch, to avoid that payments are sent to the wrong bank account due to a mismatch.

You can resolve the mismatch by running the Update bank information processing from the Accounting document table. If the mismatch was intentional or correct, you can delete the error status and process the document again.

The feedback connected to this update is being closely monitored, and the process may be improved further at a later point.

2025-11-04

Improved dialog in Product-/account search processing

The dialog for Product-/account search processing in the Company information table has been formatted and visually updated for better clarity and ease of use.

Handling of invoices with rounding

Previously, when no cost accounts had been suggested by the supplier or other settings, the rounding line wasn't always calculated, which lead to difference on the batch. Now, the rounding line is calculated after applying accounting rules, and cost accounts are filled in by these rules, to solve any possible differences on the rounding line.