Resolving Duplicate Records in DAC8 Reports

Category: Troubleshooting Last Updated: 2026-02-12

---

Overview

Duplicate records in DAC8 reports can lead to inflated transaction volumes, incorrect aggregated amounts, and potential inquiries from tax authorities. Identifying and resolving duplicates before submission is a critical step in the reporting process. This article explains how duplicates arise, how to detect them, and strategies for deduplication.

---

Problem: Duplicate Records Appear in the Report

How Duplicates Occur

Duplicates can enter the reporting pipeline through several channels:

• Multiple accounts per user. A single individual may hold more than one account on the same platform, sometimes under slightly different name spellings or email addresses.
• Data source overlap. If report data is pulled from multiple internal systems (for example, a trading engine and a wallet service), the same transaction may appear in both data sources.
• Re-processing errors. Running the report generation process multiple times without clearing prior results can produce duplicate entries.
• Migration artifacts. Platform migrations or database merges may create duplicate user records or transaction records.
• Corrections and resubmissions. When correcting a previously submitted report, original records may inadvertently be included alongside corrected records.

---

Detection Methods

1. Unique Identifier Checks

The most reliable deduplication method relies on unique identifiers:

• Transaction IDs. Each transaction should have a unique internal identifier. Check for duplicate transaction IDs in the report output.
• User IDs. Each Reportable User should appear only once per reporting period (or once per jurisdiction, if multi-residency applies). Check for duplicate user identifiers.

If your data model assigns unique IDs consistently, a simple duplicate check on these fields will catch most issues.

2. Fuzzy Matching on User Data

When unique IDs are not available or reliable (for example, across merged databases), fuzzy matching on user attributes can help identify likely duplicates:

• Match on combinations of name, date of birth, and TIN.
• Be cautious with name-only matching, as common names will produce false positives.
• TIN matching is generally more reliable, but only if TINs have been collected and validated.

3. Transaction-Level Deduplication

For transaction records, check for entries that share:

• The same timestamp (or very close timestamps).
• The same crypto-asset type and quantity.
• The same counterparty or wallet address.

Records matching on all these attributes are strong candidates for duplicates, but manual review is advisable before removing them, as legitimate identical transactions can occur.

4. Aggregate Cross-Checks

Compare the aggregated totals in your report against independent source data:

• Total transaction count per user.
• Total consideration amounts per user.
• Total units of crypto-assets transferred per user.

Significant discrepancies may indicate duplication (or missing records).

---

Deduplication Strategies

Strategy 1: Deduplicate at the Source

The most effective approach is to prevent duplicates from entering the report at all:

• Use a single authoritative data source for each data element (one system of record for transactions, one for user identity).
• If multiple data sources must be combined, define clear precedence rules (for example, the trading engine is authoritative for trade transactions, the wallet service for transfer transactions).

Strategy 2: Deduplicate During Report Generation

Apply deduplication logic as part of the report generation pipeline:

• Remove records with duplicate transaction IDs.
• Merge user records that match on TIN and date of birth, consolidating their transactions under a single Reportable User entry.
• Log all deduplication actions for audit purposes.

Strategy 3: Manual Review for Edge Cases

Automated deduplication may not resolve all cases. Flag records for manual review when:

• Fuzzy matching produces uncertain results (for example, similar but not identical names with the same TIN).
• Two user accounts have different TINs but appear to belong to the same person based on other attributes.
• Transaction records are nearly identical but have minor differences that could indicate either a duplicate or a legitimate separate transaction.

---

Handling Users with Multiple Accounts

When a single individual holds multiple accounts on the same platform:

1. Identify linked accounts. Use KYC data, TINs, and other identity attributes to identify accounts that belong to the same person.
2. Consolidate for reporting purposes. DAC8 reporting is per Reportable User, not per account. Aggregate all transactions across linked accounts into a single report entry for the user.
3. Maintain the mapping. Keep a clear record of which accounts were consolidated and why, in case the tax authority requests clarification.
4. Avoid double-counting. When consolidating, ensure that the same transaction is not counted under each account separately.

---

Post-Deduplication Validation

After deduplication, run these checks before submission:

• Verify that no legitimate records were incorrectly removed.
• Confirm that aggregated amounts still reconcile with source data.
• Ensure that the total number of Reportable Users and transactions is consistent with expectations.
• Review the deduplication log to confirm that all removals and merges are documented.

---

Disclaimer

This article provides general operational guidance. The handling of duplicate records may be subject to specific rules or expectations from your national tax authority. Always verify your approach against the applicable regulations and, where appropriate, seek professional advice.