Timestamps for items on duplicated jobs between 7 May 2026 and 21 July 2026 were showing as the date the job was duplicated – rather than preserving the timestamps in the original job.
There are a few key points to note:
- Not all firms had duplicated jobs during this period
- Not all firms with duplicated jobs during this period were affected for the entire period
- Job snapshots are all correct, so the original data can be observed by creating another duplicate from the original snapshot
- All affected firms with impacted data were individually notified (see recovery below).
Recovery
We became aware of this on the 21th July 2026, the system was promptly changed to work as it previously did – meaning timestamps on duplicated jobs preserve the timestamps in the original file going forward.
We investigated the database to find all affected firms and client files and there was two distinct cases we found.
Jobs not yet rolled over:
For jobs duplicated in this period that were not yet rolled over, we found a solution to re-sync the item dates with the snapshot data. We ran this across all affected client files. The change was non-destructive as we were only adding to the data rather then removing or changing anything. No further action is required.
Rolled over jobs:
Jobs that were duplicated for the purpose of re-rolling simply had to be rolled back and rolled over again. In many of these cases the PDF was correct, however, we suggest doing this anyway just to be safe. All affected firms were notified.
Jobs that were duplicated and then worked on before rollover had a higher chance of impacted data. For these jobs we created an automated fix that would re-generate the PDF and then attach it into the zip file. The main PDF file is left unchanged, but a "recovery" file is added into the zip file. The users were then notified and asked to download the zip file again.