Abakion Legal 27.1.202625.6032 & Abakion Legal DK 27.1.202625.6034

It is now possible to have dates in document templates formatted according to the template's language code. Previously, only the two fixed formats dato_kort and dato_lang were available, both of which always used Danish date formatting regardless of the template's language.

To apply language-sensitive date formatting, the Date Format field on the relevant data source line must be set to 1 or 4 for a long date format with the month name written out (e.g. 3 June 2026 in British English, June 3, 2026 in American English, 3. juni 2026 in Danish, 3 Juni 2026 in German), or 2 for a numeric date format with the full year (e.g. 03-06-2026 in Danish and European languages, 2026-06-03 in German).

Note: Language-sensitive formatting only works when the Date Format column is used on the data source line. If the Format column is used instead, the template's language code is ignored and the date is always formatted using the specified format string regardless of language.

The template's language code is taken from the Language Code field on the document template. It also requires that the language in BC's language list has a valid ISO language code (e.g. EN-GB, EN-US, DE-DE). If the ISO code is missing, the system falls back to Danish formatting.

Previously, the Duration field could only be filled in for tasks of the type Meeting. For all other task types — e.g. Call, Follow-up, and Blank — the field was greyed out and could not be edited.

The Duration field is now active for all task types. It can be filled in via Create Task on the Extended tab, as well as on the Task Card. The field is not mandatory and can be left empty.

It is now possible to add a free-text comment directly on a client payment entry in the Client Payment Entries list. The comment works as a personal note attached to the entry, but does not affect posting or bank export.

The comment is displayed as a column in the list and can be used for searching and filtering. To write or edit a comment on an entry, use the Edit Remark action in the ribbon, which opens a small dialog page where the field can be edited. The page saves automatically on close.

In addition, a new action, Validate Unexported Entries, has been added. This action goes through all unexported entries and updates any error messages in the Export Error Message column. The column is now displayed in red text when an error is present, making it easy to spot entries that require attention.

When an employee's total time registration for a given day exceeded the permitted maximum, the affected lines were flagged with an error and displayed in red on the Time Registration Lines page. The issue occurred when a user subsequently corrected the error — for example by reducing the hours on one of the lines — but the other lines for the same day remained red, even though the total time was now correct.

This meant that the user saw error indicators on lines that were actually fine, which could cause confusion about whether the registration had been approved.

This has now been fixed. All time registration lines for the relevant employee and date are automatically updated when a change is made. The error indicator disappears from all lines as soon as the total registered time is within the permitted maximum.

If a time entry referenced a dimension value (e.g. a department or project) that had subsequently been blocked in Business Central, the entire background queue would fail. This meant that not only the failing entry, but also all subsequent time entries in the same run, were never processed — and without the user receiving any notification about what went wrong.

The fix ensures that the background queue now handles errors per entry: if one entry fails due to a blocked dimension, it is marked as failed with a descriptive error message, and processing continues with the remaining entries.

In addition, an early validation has been added directly in Time Registration: the system now checks before posting whether an entry's dimension values are blocked. If a blocked dimension is detected, the line is marked as failed with an error message visible in the user interface — so the issue can be corrected before it is even attempted to be posted.

When using Reverse/Re-create on a posted invoice where the matter used fee dimensions — for example to record a referrer as a dimension value on finance and matter entries — the dimensions were not correctly transferred to the credit memo and the new re-created invoice.

The result was that when the user subsequently changed the status on the re-created invoice, they received the error message: Dimension code XXXXX not found for Invoice ####. This is mandatory.

The issue has been fixed. Fee dimensions are now correctly transferred to both the credit memo and the re-created invoice when using Reverse/Re-create, and status changes can be completed without errors.

When creating a new sub-matter on a matter with many existing sub-matters, the system could fail with the message "The record in table Contact already exists". The error occurred when the number of sub-matters crossed a round number — for example at the transition from 9 to 10, from 99 to 100, or from 999 to 1000 sub-matters.

The cause was that the system found the most recent sub-matter number using text sorting rather than numeric sorting. This meant that e.g. "Matter-99" was considered "more recent" than "Matter-100", and the system then attempted to create "Matter-100" again — even though it already existed.

The issue has now been fixed so that the system always finds the correct next available sub-matter number. The fix applies both to direct matter creation in Abakion Legal and to creation via CMI.

When clicking the Filing button in the Abakion Legal basis role centre, an error occurred if the email being filed had many recipients in the To or CC field. The error prevented the filing from completing.

The cause was that the list of email recipients in certain cases exceeded the permitted character limit of 250 characters before being saved. The fix ensures that the recipient list is now correctly truncated, so filing completes without errors — even for emails with many recipients.

In the Invoiceable Hours per Employee report, the system ignored the date filter specified by the user when running the report. Regardless of whether a single monthly interval was selected, for example, the report showed time data and amounts for the entire period.

The cause was that the report did not apply the selected Date Filter when retrieving data from matter entries. This has now been fixed.

The report now only shows invoiceable hours and amounts within the selected date interval.

During customer post-application, the liability calculation could produce incorrect results from the second posting onwards. The liability calculation was not correctly reset, and exchange rate gains/losses were in some cases not posted to the correct general ledger account (Liability/receivable).

The issue has now been fixed so that the liability calculation works correctly for all postings — including when application is performed multiple times on the same matter.

Additionally, a bug has been fixed where the liability level from the application entry was not correctly transferred to the adjustment entry.

When using the Split Collect Payment function on a line with a collect invoice in the payment journal, the new lines were in some cases created without amounts or with an incorrect sign.

The issue has now been fixed. The new lines are correctly populated with the amounts from the associated invoices, and the total payment is distributed precisely across the lines.

If an Azure AD group was renamed in Entra AD, the Security Group Members FactBox on the matter still displayed the old group name — even after synchronisation with Azure had been run.

The cause was that the group name on existing matters was saved as a snapshot at the time of creation and was not updated subsequently. The actual permissions in SharePoint were correct, but the outdated name could cause confusion for users.

The fix ensures that the next time Azure groups are synchronised — either via the job queue or via the manual Get Azure Groups action — the group name is automatically updated on all matters where the group is assigned. Existing matters with an outdated group name are corrected automatically at the next synchronisation, with no need for manual cleanup.

When looking up CVR numbers on contacts in Abakion Legal DK, the lookup could fail with a text length error message if the company being looked up had a particularly long industry description from Virk. The error occurred for example with companies in the financial services industry sector, whose description exceeds 100 characters.

The cause was that the industry description from the Virk API was saved directly into the Industry Group – Description field, which has a maximum length of 100 characters. When Virk returned a longer text, the system aborted with an error rather than saving.

The fix ensures that the industry description is automatically truncated to the field's maximum length before being saved, so the CVR lookup always completes without errors. The industry code itself is saved unchanged and remains the key business information.