Once a new recon process is setup, tested and ready to be used for your operations, ‘exceptions workflow’ should be enabled for a full set of user interactions with the results.
Recommendation
Enable 'exceptions workflow' for all live reconciliation processes. Begin with straightforward automation for simple exceptions, then progressively enhance capabilities by incorporating automation, monitoring, and ageing rules as operational needs evolve.
Key benefits:
- Accurate risk management by grouping and categorising exceptions.
- Efficient investigation and resolution for processes of all sizes: single user or small teams, to global operations.
- Full auditability of every step, with a clear trail of ownership and actions taken.
- Automated repetitive actions so that analysts can focus on high-value investigations e.g., team assignment based on asset classes, auto-closing, low-value exceptions.
- Business intelligence and operation management have rich statistics and trend analysis.
Using dashboards to monitor and prioritise
Once reconciliations are complete, having clear oversight of outstanding exceptions is essential.
Duco’s intuitive, in-app dashboards make it easy to monitor, prioritise, and act on exceptions - giving every user role-specific visibility and control while driving collaboration and operational efficiency.
With persona-based dashboards, users see what’s relevant to their role. Filters and drill-downs help refine focus and take action directly within the platform.
Role-based access ensures data segregation, while saved and shared views enable consistent oversight across teams.
Together, these capabilities empower smarter decision-making, stronger governance, and continuous operational improvement.
Recommendation: Use Duco’s configurable dashboards to create focused, role-specific views that highlight the most material exceptions.
Encourage teams to:
- Apply filters to isolate key exception groups.
- Drill down to investigate and resolve directly in-platform.
- Save and share dashboards to align oversight and drive collaboration.
- Regularly review dashboard content to ensure relevance and continuous improvement.
Key Advantage: Any user with 'Dashboard Administrator' role can directly set up dashboards in any environment - sandbox, UAT, Prod - without IT intervention, making it easy to deploy, iterate and scale oversight quickly.
Exception categorisation
When there are large volumes of exceptions across reconciliation, it’s hard for teams to filter, prioritise, and report meaningfully e.g., it can be challenging to find at a glance which exceptions are high-priority, which are due to root cause X or which are most frequent for region Y.
Without structured categories, exceptions become noise: the process slows, issues are overlooked, governance is weak and you may lose insight into underlying patterns.
The exception categorisation feature addresses this: it allows you to group exceptions via meaningful, well-defined categories in the results view, thereby improving investigation and analysis, prioritisation, reporting and remediation efficiency.
By tagging exceptions with e.g., region, asset class, root cause you turn raw exceptions into structured operational intelligence - enabling you to see where inefficiencies are, why the mismatch occurred, which team owns it, what region/product impacts, and therefore act faster.
See here for more details on how it works and how to enable it.
Best practice recommendation:
At the global setting level these categories, once set up, are available to all processes within the particular environment. While the maximum limit for these categories is 100, we recommend keeping the number closer to 25 to ensure they remain meaningful and easier to manage. These categories should be reviewed annually (or more frequently if needed).
For each category, we recommend an upper limit of 10 options to make organising them and exception assignments simpler and more efficient.
Ageing
Accurate exception ageing is important for work prioritisation, risk management and operation process optimisation.
There are three ways to set ageing: by using the default setting, through a calculated result that combines multiple data points, or via a workflow rule for more dynamic control. For detailed guidance and best practices, see the Exception age article.
To achieve this, it’s essential to understand how reconciliation types (Delta vs. Replacement) interact with record tracking, carry-over, and auto-closure configurations.
Reconciliation types
Replacement reconciliation:
-
Definition: The whole data set is submitted in each run, and completely replaces the previous dataset.
Duco overwrites old records with the latest input file. Any items missing in the new file are assumed to no longer exist. - Example: Daily positions file containing all open positions as of end-of-day.
Delta reconciliation:
- Definition: Each run contains only changes (deltas) since the last load – new, amended, or cancelled records. Duco appends changes onto the existing dataset and retains prior unmatched / partially-matched items until they are matched, closed, or resolved.
- Example: A trade booking system that sends only today’s changes (new trades, modifications, cancellations).
Exception handling across days (when configuration changes)
Sometimes you may need to update the process configuration after the process is already live and has open exceptions. This section describes what to look out for and how to better prepare for it.
Scenario
When reconciliation configurations (e.g., record tracking fields) are modified after an initial run:
- Existing exceptions remain linked to original configuration:
- Exceptions generated before the configuration change remain tied to the logic in place when they were created.
- They will not be re-evaluated using the updated configuration.
- Exception metadata does not carry forward:
- Any categories, comments, or other metadata applied to exceptions before the change will not transfer to exceptions under the new configuration.
- New records follow updated configuration:
- Records processed after the change will follow the updated logic.
- If a previously tracked field is added or modified, the same record may be treated as new, and prior exception history (comments, labels, age) will not accrue.
Example Scenario
- Day 1: Reconciliation runs with the initial tracking fields: Trade ref, value, lots. Exceptions are created based on this configuration.
-
Day 2: Configuration is updated to include Trade date in addition to the original fields.
- Exceptions from day 1 persist under the old logic (Trade ref, value, lots).
- New records are evaluated under the updated logic (Trade ref, value, lots, trade date).
- A record appearing in both configurations may now generate a new exception, and previous comments or labels will not carry over.
Best practice before activating a new configuration:
- Tag existing exceptions with a timestamp or version identifier by either creating a separate non-matching (information-only) field or use categories to clearly indicate the configuration version they belong to.
- Close legacy exceptions whenever the record tracking keys are modified.
- Preserve labels/categories and comments by using reference data: match the mandatory fields to a reference table to temporarily migrate and repopulate the labels and comments.
Advantages
- Clear traceability between old and new configurations.
- Prevents data inconsistency or confusion from legacy exceptions.
- Simplifies audits - each exception is tied to its config version.
- Ensures accurate operational reporting across changes.
Consequences if skipped
- Old exceptions may persist incorrectly.
- Labels/categories/comments may be lost or mismatched.
- Audit trail breaks - unclear which config created which exception.
- Reporting inaccuracies when comparing exception counts.
Use record tracking and auto-close
Record tracking links each record across runs, while auto-close carries forward labels and comments from carried-over exceptions to the next run. See here for more details.
Recommended best practices for these features :
-
Enable record tracking for all delta reconciliations.
Benefit: This ensures continuity and prevents duplicated effort across runs.
If skipped: Each run may re-process the same exceptions, wasting time. -
Use auto-close on record tracking fields.
Benefit: this automatically ages and carries forward labels and comments for exceptions.
If skipped: manual follow-up is required, increasing the risk of missed unresolved items. -
Set a conservative lookback (one run by default).
Benefit: Balances continuity and system performance.
If skipped: Excessive carryover can cause confusion and slow down reconciliation. -
Use match fields for auto-close only when tracking fields are insufficient.
Benefit: Handles complex cases where uniqueness is not captured by tracking fields.
If skipped: Exceptions may close incorrectly or remain unresolved, creating operational confusion.
Carryover recommendations
-
Full population transaction reconciliations usually do not require carryover.
Benefit : This simplifies setup and speeds up processing.
If skipped: Minimal impact; only a small risk of misinterpreting exceptions. -
Delta transaction reconciliations must use carryover, limit record tracking to occurrences in the previous 3 runs only.
Benefit : This tracks unmatched changes and reduces duplicated effort.
If skipped: Unmatched exceptions may be lost, resulting in repeated work. -
Trade reconciliations should have carryover enabled.
Benefit : This maintains consistency across multiple days.
If skipped: Old exceptions may be missed, causing operational confusion and issues. -
Ad-hoc or repeating submissions should use auto-close on match fields only if tracking fields are insufficient.
Benefit : This handles unique repeating records efficiently.
If skipped: Duplicates or unresolved exceptions may persist
Match fields vs. record tracking fields
When record tracking fields are a subset of match fields, the system may interpret records differently across processes:
- For record tracking, those records are treated as the same and tracked as one ongoing entity.
- For auto-closure, the broader match fields may cause the system to treat them as different, closing only one record at a time.
This means that while one record continues to carry forward, exceptions may remain open in older runs—leading to confusion or incomplete closure.
-
Use record tracking fields for auto-close whenever possible to maintain consistency and clarity across runs.
Benefit : Ensures accurate carryover and a complete exception history.
If skipped: Exceptions may not be linked correctly, requiring repeated investigation. -
Use match fields for auto-close only in well-validated scenarios where differences in closure behavior are intentional and clearly understood.
Benefit : Supports complex exception resolution.
If skipped: Exceptions may close incorrectly or remain unresolved across runs.
Validate configurations through test runs to ensure that tracking and closure logic align with business expectations.
Mapping business processes to workflow rules
In large organizations, exception management often involves multiple teams with distinct responsibilities. Without proper controls, exceptions can be allocated incorrectly, causing confusions, duplicate actions, delayed resolutions, or missed tasks.
Duco’s group assignment restriction feature enables organisations to implement structured, risk-mitigated exception flow, ensuring that exceptions can only be passed to appropriate teams, while maintaining full visibility and operational flexibility.
By using group assignment restriction, users from one group can only pass exceptions to other groups that are allowed in the configuration, thus controlling the flow. In the above example, users from MO FX can only allocate an exception to the global middle office, not any other group.
A default group is always allowed to intervene to prevent orphaned exceptions.
Practical use cases
- Triaging team → middle office / accounting team: Prevent exceptions from being incorrectly sent to unrelated teams.
- Reconciliation analysts: Accurately model the exception flow to reflect organisational responsibilities.
- Default team members: Maintain visibility across exceptions and assign to any team as necessary.
- Other reconcilers: When reallocating exceptions, choices are limited to whitelisted groups and the default group.
Best practice recommendation
- Define groups clearly: Ensure all teams and their responsibilities are well-documented before configuring workflow rules.
- Whitelist only relevant teams: Limit allocation options to necessary groups to prevent misrouting.
- Monitor exception flow: Regularly review exception allocations to ensure adherence to workflow policies.
- Maintain default access: Always allow assignment back to default groups to prevent orphaned exceptions.
Leverage roles for segregation: Combine workflow orchestration with investigator (who can only see the exceptions assigned to their group) and operator roles for granular access control.