We're pleased to announce the latest release of Access Legal Case Management, Version 2.16.8.
This update includes various enhancements and bug fixes detailed below. A PDF copy of the release notes can also be found here.
Email CC Field: Multiple Recipients Now Correctly Separated
Previously, when running a template in the Conveyancing (CP) application, multiple email addresses in the CC field were displayed as a single merged string rather than as individual recipients. This occurred across the To, CC, and BCC fields when addresses were separated by semicolons.
This has been resolved. Email addresses provided in templates are now correctly split into individual recipients, ensuring emails are addressed and delivered as intended.
Posting Period Incorrectly Displayed as 0 for Bill Authoriser on Last Day of Financial Year
On the last day of the financial year, bills raised by case users were displaying a posting period of 0 when viewed by the Bill Authoriser in the Authorisations screen. This prevented the authoriser from editing the bill — only Authorise or Delete options were available — even though the correct period (e.g. 202412) was still active. This issue was specific to Access Legal Case Management (ALCM) and did not affect One Office.
The system now correctly identifies and displays the active posting period when a bill is viewed on the last day of the financial year. Authorisers can edit bills as expected in this scenario.
Bill Authorisers reviewing bills raised on the final day of a firm's financial year.
Workflow Email (SEB) Now Respects Configured Default Font
When creating an email via the SEB (Send Email from Workflow) command, the email body was displaying in the browser's default sans-serif font instead of the firm's configured default font (e.g. Calibri). The font picker in the email editor toolbar would show "sans-serif" rather than the expected font, making outgoing correspondence appear inconsistent with the firm's branding.
The root cause was that when a workflow email was opened, the font detection logic could encounter an unstyled or mixed-content area in the email body and incorrectly read the browser's fallback font value, applying it as the active font setting.
This has been resolved so that the configured default font is now correctly applied when opening a workflow-generated email, ensuring the font picker and email body both reflect the firm's configured default font and size.
Billing Guide – Time Analysis: Date Ordering Now Respected When Grouping Is Disabled
Fixed an issue in the Billing Guide where selecting Analysis Type = Time, Sort By = Date, and Group By = None still displayed entries grouped by Fee Earner, breaking chronological order. Time entries are now listed in strict date order when no grouping is selected, correctly reflecting the user's chosen report settings.
eChit Rejection Now Recorded in File History
Previously, when an authoriser rejected an eChit request via the Authorisations screen, no entry was created in the matter's File History — leaving the rejection entirely unrecorded in the matter diary.
This has been resolved. The File History will now correctly display a new row when an eChit is rejected, showing the Date Done, Folder, Type (FN), and a note in the format "Rejected by [user initials]". This applies at any stage of the authorisation workflow, including cases where a Level 2 authoriser rejects an eChit that has already received Level 1 authorisation.
Opportunity Quote – Costs Credit Limit Now Populates Correctly
When opening a case from an Opportunity Quote, the Costs Credit Limit field on the Matter screen was being populated with an incorrect value. Instead of reflecting the net Professional Costs figure from the quote, the field was showing approximately 80% of the total quoted fees — for example, £800 instead of £950 on a £1,000 quote at 20% VAT. The same incorrect figure was also appearing in the corresponding OneOffice Matter screen.
This has been resolved. The Costs Credit Limit field now correctly uses the net Professional Costs value from the Opportunity Quote when a case is opened.
Duplicate Records Created on Single User Actions
Case management — client profiles, diary entries, case note and email/document attachments
Performing a single action such as saving a client profile, adding a diary entry, or attaching an email or document to a case could occasionally result in two identical records being created simultaneously. No error message was shown, making duplicates difficult to detect.
Server-side guards have been added to the affected endpoints, ensuring that a single user action can only ever create one record, regardless of how the request is processed internally.
Conflict Check Enhancements
Overview
Two enhancements have been made to the Conflict Search feature to improve clarity and compliance support for law firms.
Change 1: "Client Name" Renamed to "Conflict Name"
The column heading previously labelled Client Name in the Conflict Search has been renamed to Conflict Name across all relevant areas of the product.
This change addresses a long-standing inaccuracy: the Conflict Search returns results that include not only clients but also contacts and other parties. The previous label of "Client Name" was therefore misleading, as it implied results were limited to clients of the firm.
What has changed
Conflict Search Screen — The column heading was previously resolved dynamically from a system value, which displayed as "Client". This has been updated to use a static label: Conflict Name.
Conflict Search Output PDF — The printed conflict search report previously displayed Client Name as the column header. This has been updated to Conflict Name to ensure consistency between the on-screen view and the printed output.
Why this matters
Law firms are required to run conflict checks not only against existing clients but also against contacts and other parties associated with matters. Using the label "Client Name" was causing confusion for users who could not reconcile why non-client results were appearing under a client-specific heading. This change removes that ambiguity.
Change 2: Speciality Field Added to Conflict Search Results
A new Speciality column has been added to the Conflict Search results grid.
What has changed
The Speciality field is now displayed within the Conflict Search results grid, alongside existing columns such as Ref, Name, Details, Postcode, DOB, and Match.
The data is sourced from existing Speciality values stored against Contacts and ContactCompany records — no new data entry is required.
Why this matters
Identifying a person's speciality (for example, a medical expert, financial adviser, or other professional) is essential to the Personal Conflicts compliance check that all law firms are required to conduct. Previously, users had to navigate away from the conflict results to look up this information separately. Surfacing the Speciality field directly within the Conflict Search results significantly streamlines this process and reduces the risk of oversight during the conflict-checking workflow.
Notes
No configuration changes are required to benefit from these updates.
The Speciality field will only display a value where one has previously been recorded against the relevant Contact or ContactCompany record.
Both changes apply to Conflict Searches run from the Client screen and the Matter screen.
Conveyancing: Incorrect Application Code on Prospect Matter Acceptance
When accepting a prospect/opportunity matter and converting it to a live matter within a Buying and Selling (linked sale and purchase) quote, the application code assigned to the second matter was hardcoded as CS (Convey Sale), regardless of how the opportunity was originally set up.
This caused the file history to display items for the wrong application code, resulting in missing or incorrect history entries.
This has been resolved. The application code is now correctly carried over from the original opportunity setup when the matter is accepted, ensuring both matters in a Buying and Selling quote receive their intended application codes (CS or CP). File history will now display all relevant items without requiring any manual correction.
Time Entry Edits Not Persisting
Changes made to time entries within the Import Time dialog (editing fee earner allocations or bill amounts) were not being saved back to the Billing Request screen when clicking OK. The original values remained visible and the Bill Total did not update.
This has been resolved. Edited time entries are now correctly applied to the Billing Request screen, with updated allocations, amounts, and Bill Total recalculating as expected.

