You imported an August file, then downloaded August 29 through September 3 to investigate a question. Both files may be genuine, but the days they share need attention. Appending the second file in full can count late-August activity twice.
Check scope intersections before deciding that individual rows are duplicates. The examples below are fictional. Similar times and equal quantities are clues, not proof that an event has been repeated.
Review the export register first
Compare account, asset filters, time zone, and original date selections. Two accounts exported for the same month overlap in time but do not necessarily contain the same records.
| File | Scope | Initial treatment |
|---|---|---|
| August original | Account A, full month | Already adopted |
| Boundary supplement | Account A, late August to early September | Review shared period |
| Second account | Account B, full August | Reconcile separately |
Retain what was actually selected in the platform. A local period label such as “August” may hide whether an ending date was included. Inspect returned records around the boundary or consult the current export description before making assumptions.
Is the new file a replacement or an addition?
Decide its purpose before importing. A new version of the same period is a replacement candidate, not automatically new activity.
If the objective is to add September 1 through 3, identify that new interval explicitly in a working copy and retain the filtering rule. If the supplement contains valid August records missing from the earlier export, investigate those differences before replacing the old version or adding supported entries.
A later file may also show an updated status for an existing event. Preserve retrieval times and compare the event's meaning. “Newest file wins” is not a sufficient explanation for every change.
What confirms a duplicate?
A reliable identifier, account, record type, and source context usually provide stronger evidence than amount and time alone. First establish whether an identifier refers to an order, a trade, or another kind of event: one identifier may legitimately connect several detailed rows.
Without a unique identifier, use time, asset, direction, quantity, and remarks to find candidates. Multiple real activities can share those features. An automatic remove-duplicates command can therefore delete valid records if its comparison columns are not genuinely unique.
Add a candidate group and decision status in the analysis. Once duplication is confirmed, exclude the extra counting while retaining both originals and the reason. A decision should be recoverable if later evidence changes it.
Can the balance difference validate the decision?
It can support a check, but it cannot replace event evidence. Missing and duplicated records can offset each other.
In a fictional example, an asset opens at 100, receives 10, and closes at 110. Counting the receipt again produces 120. After confirming that the same event was counted twice, excluding the second count restores 110. In a real ledger, a difference of 10 does not justify deleting any convenient 10-unit row.
Review row-count changes, asset net changes, and the closing result separately. Each should follow from the actual excluded records. Do not keep deleting near-matching amounts until a preferred total appears.
How can the next export avoid rework?
Record coverage and adoption status for each export. New files should pass an overlap review before entering cumulative calculations.
- Label a second export of an existing period as a review version.
- Keep its time zone and ending-boundary convention.
- Record the last reconciled period, not merely the last download date.
- Separate the shared and new portions of a cross-month file.
- Retain exclusion reasons so mistaken decisions can be reversed.
Recap's Binance file guidance also warns about overlapping periods when importing multiple files. That is guidance for its workflow, not proof that every other tool uses the same duplicate detection. Check your chosen tool's behavior.
Do a few overlapping rows need a log?
Yes, but it can be short. Identify the files, shared period, evidence, and adopted treatment. Small manual changes are especially easy to forget when the same files are revisited later.
If a candidate remains unresolved, keep its possible impact and asset visible rather than quietly deleting it. Update the decision when the supporting records arrive.
What if there are overlaps and gaps together?
Track them separately. A repeated month-end entry cannot compensate for a missing mid-month wallet record, even if the total looks close.
Draw a timeline with a row for each account and mark the intervals supplied by adopted files. Distinguish shared intervals from uncovered ones. Then verify actual coverage using known events; the diagram only checks the scope you registered.
For a quiet interval, record the evidence that it had no activity. For an unchecked interval, create a retrieval task. When the missing file arrives, inspect its joins with neighboring files before adopting it. If duplicate-looking rows already exist within one original, investigate their meaning there too: they may describe separate events or status changes rather than an export error.