Duco has a sophisticated exceptions workflow to support our customers in their exception investigation processes. This document is intended as a briefing for:
+ Business analysts to help with designing workflow processes in Duco
+ Operation analysts to guide interaction with the platform during an investigation
+ Operations managers to give an overview over the capabilities of Duco's exception workflow solution
The document covers the following:
+ Investigations best practice describes how a best practice workflow would work on a day to day basis
+ Achieving best practice focuses on how to set up the best practice workflow described above
+ Alternative workflows discusses some alternative ways to manage workflow available in Duco
+ Investigation overview describes how to get an overall view of the status of investigations
This document is intended as a companion to the Duco reference documentation and training provided by client services. Our roadmap documentation gives an overview of upcoming, planned workflow features.
Investigations best practice
A typical flow of exception investigation in Duco consists of the following stages:
As soon as a process has run, typically, as soon as the files have been delivered, users responsible for break investigation will receive an email notification with a summary of that particular run.
This will show
- number of matched items
- number of partially matched items
- number of unmatched items (for each side)
- any errors that may have occurred
To protect your data, the results themselves are not sent via email. It is possible to extract these via our Rest API.
If no files (or only a subset of files) are received by a user defined deadline, Duco
- will send an email notification of a missed deadline if no data has arrived
- run the process with any data that has arrived within the defined window
Depending on the reconciliation process, there may either be a single individual, a single team or a group of teams responsible for investigating and driving breaks to resolution.
If a group of teams is responsible, a more extensive triage process would typically be performed by a single team initially. This team would allocate out the exceptions to the teams’ responsible and apply labels to indicate priorities of breaks (“high value break”).
The triage stage would typically look as follows:
Duco can help focus the triage process by:
- customising the way exceptions age based on underlying economics (e.g. the trade date)
- automating parts of the triage and break prioritisation process by allowing you to synthesise columns for prioritisation and triage (see below for details):
It is also possible for this triage process to be performed in a more decentralised way (see below for details).
If either an individual or a single team is responsible, the triage process is managed in a more flexible fashion:
Either a team leader may assign out exceptions to be investigated in bulk or individuals may self-assign any exceptions that they are intending to look at.
Operators then perform investigations on the individual items assigned to them. The order in which items are tackled may depend on the triage process described earlier including factors such as the exception’s age or the value of the break.
When investigating the item, the operator will start review on the item to indicate that they have started looking at the item. If the operator cannot close the item themselves (see below), they may email or talk to internal / external stakeholders to ascertain the root cause of the problem and ask them to amend their source systems. They will then
- leave comments on the issue to maintain a record of the conversation
- label the item to indicate the root cause of the item
After the root cause has been established, a number of actions are open to the operator to bring the investigation to a close. The operator selects the one that is most appropriate depending on the situation:
- Mark an item as pending resolution
If the item has been corrected in the source system (either by the operator himself or by an internal / external stakeholder) and the correction will be contained in a subsequent run, the operator should mark the item as pending resolution. (It will automatically be closed when the corrected version is included in the next run.)
- Close the individual exception
If the item cannot be corrected in the source system or will not be fed back into the reconciliation, but a future occurrence of the same problem should lead to another exception that will need to be investigated again, the operator should close the exception.
- Break apart a full or a partial match
If an item was paired with another item and these do not belong together, the operator can break these items apart. New exceptions will be created for the unmatched items. If an operator finds himself frequently breaking apart items, he should consider amending the automated match rules.
If items with the same problem are expected to re-occur in future runs, but do not need to be manually investigated again, Duco provides a set of actions that will help the operator by automating repetitive actions:
- Manual match two unmatched items
An operator would typically manual match two items together if the items themselves are correct, but were not automatically identified as belonging together (e.g. because the match rules do not cater for this specific case). After manual match has been selected, these items will be force matched together: If the two items again occur in a future run, they will be automatically matched together.
If an operator finds himself frequently manually matching items, he should consider amending the automated match rules.
- Force closing a partial match
An operator would typically force close a partial match, if one side of the partial match is incorrect, cannot be corrected, is likely to occur again, but will not need to be investigated again. If the two items again occur in a future run, they will be automatically force closed and their exception will be set to closed.
- Force closing an unmatched item
An operator would typically force close an unmatched item, if the item may occur in future runs, but the other side of the item is not expected to be submitted. If the item occurs again in a future run, it will not be matched against items from the other side, but instead will be automatically closed and the exception will be set to force closed.
The above decisions can be summarised in the following decision flow:
Exceptions will continue to age in Duco until one of these specific resolution actions has been taken.
Corrective action by a senior stakeholder
Sometimes, the investigation may be performed by a team, but manual, corrective action (as opposed to re-submission of corrected data) can only be performed by team leaders. In these circumstances, team leaders can be configured to be the only ones who have rights to
- Close exceptions
- Force close exceptions
- Manually match items
The next run will of course include new items for further investigation, but it may also contain corrections of existing items or even items which continue to exhibit the same problems as before. The below gives a broad overview of the behaviour in Duco. The mechanics of how Duco identifies whether an item is the same item and whether it exhibits the same problem or not are described in detail in the appendix (see below).
If a correction or additional data was submitted, that will lead to
- a previously partially matched item now being of a full match
- a previously unmatched item now being part of a full or a partial match,
we will automatically close the original exception from the previous run.
Exhibiting the same problem
In a similar vein, if a particular item is submitted again in the latest run and continues to exhibit the same problem, this will also lead to the item being closed in the old run. To guarantee continuity in the investigation, the status of the exception, who the exception is allocated / assigned to, its age, comments & labels will be copied to the occurrence of the exception in this latest run.
Exhibiting a different problem
If a partial match or an unmatched item now exhibits a different problem, a new independent exception will be created which will need to be investigated and corrected independently of the original exception.
Previously manually matched items
If two items that were previously manually matched occur again in this run, the items will be automatically force matched together – even if other pairs in the run provide a better or perfect match.
NB: It is possible to remove this force match pairing by “reopening the exception ” in the latest run.
Previously force closed items
If the same partial match that was previously force closed occurs again in this run, it will be automatically force closed and the exception will be set to closed.
If the same unmatched item that was previously force closed occurs again in this run, it will not be matched against items from the other side, but instead will be automatically force closed and the exception will be set to closed.
NB: It is possible to remove this automatic force closed rule by “reopening the exception” in the latest run.
If an item was not submitted again, the exception will continue to exist and will continue to age. By making use of Duco's carry over feature, users can choose whether they would like the exception to
- exist in the previous run (carry over switched off)
- be carried over into the latest run (carry over switched on)
For most activity based reconciliations, it is typically appropriate to have carry over switched on.
Achieving best practice
To achieve the workflow described above, several elements will need to be set up in general and the reconciliation process in particular. This section describes these elements.
Relevant email recipients –i.e. members of the triage team - will need to be set up to ensure that they receive run notifications.
More information on this topic is available here.
Similar to general run notifications, it is possible to set up run deadlines and set up notifications in case these are breached:
All of the labels needed for classification will need to be set up.
More information on this topic is available here.
In an exception workflow context, record tracking should identify a unique record (e.g. a position identifier). This should be post roll up if there is aggregation. This means that the option to “track constituents” should be left unchecked. After a record tracking has been configured, can identify if a particular item keeps occurring in several runs. We can then use this information to link records and automatically close related exceptions. The exact mechanism used is described in more detail in the appendix.
Beyond its use in exceptions workflow, record tracking will also be used to detect and remove duplicates from your reconciliation. More information on this topic is available here.
Calculated results enable you to use natural language rules to create additional fields post matching. This means you can:
- Calculate the economic value of a break
- Automatically prioritise results based on criteria you define
- Simplify the triage process
Detailed management of permissions and changes to process configuration is subject to the client’s governance model: Duco is happy to support clients to implement a governance model appropriate for their needs. Separate governance documentation is available for this purposes.
Key considerations from the perspective of exceptions management are that:
- users performing triage may be separate to those performing the operations
In this case a separate group for triage and operations should be created. Default exceptions group should be set to the triage group.
- operator privileges are needed to perform workflow actions
- separate privileges can be configured for manual matching, closing and force closing of exceptions
Exception workflow settings
When to switch on exceptions workflow
It is recommended that exception workflow is switched on for an individual process as soon as the reconciliation has run through its initial development and testing phases and is ready to be used for parallel run.
As soon as exception workflow is switched on, in every subsequent run, unmatched or partially matched items will produce unreviewed exceptions which will need to be investigated or closed.
Setting up the default group
Default exceptions group should be set to be the group performing the initial exceptions triage.
Auto-close of exceptions
The best practice behaviour described above assumes that auto-closing of exceptions has been enabled for the process. A section below describes the behaviour when auto-closing of exceptions has been switched off.
By default, all matched fields are used to identify whether the same problem has reoccurred or whether a break constitutes a new problem. The best practice recommendation is to leave this option unchanged. The detailed mechanics are described in the appendix.
Several other options are available for the user to configure on the workflow settings page.
- whether to implement manual intervention controls
- whether to close unmatched item if they fall within a particular tolerance
- the option to close all exceptions if these have accumulated during the setup process
Configuration of these items does not affect the fundamentals of the exception workflow process as described in the rest of the document. Comprehensive documentation of these features is available here.
It’s possible to get a higher level overview of the progress of the investigations using a number of different views:
- for an individual process
- for all outstanding exceptions
- using our Tableau Web Data connector to customise your views
At a process level, you are able to see outstanding exceptions in the individual run or – if you are looking for a higher level overview – you are able to see the progress by run or by age.
Similarly at a global level, you are able to see outstanding exceptions across all processes.
Tableau view using the Duco Data Platform
Finally, you are able to customise your exceptions views to fit your operational processes by using our Data Platform module. For more information, please contact firstname.lastname@example.org