Distinguish an import duplicate from a real duplicate transaction

Compare the original event with the imported rows

Establish which happened before changing records so a quick cleanup does not remove a legitimate part of the account history.

When an exception needs a supplier invoice schedule, ParseMill can extract the invoice PDFs into Excel and keep source references available for checking. That gives the reviewer a concrete starting point. Bank reconciliation, accounting judgments and posting stay in your accounting system.

The practical question is where duplication occurred: in the source, during transfer, or in later recording. Each requires different evidence and an authorized correction decision. Build that evidence trail before deleting, excluding or editing financial records.

Record source and import identity separately

Capture source statement or export reference, source transaction identifier where available, source row position, import batch reference, internal record ID, date meaning, amount and currency. If identifiers are unavailable, record the limitation and compare additional context. A generated internal ID identifies a record, not necessarily a unique real-world event.

Intuit: Find missing transactions describes checking transaction states and accounts when records appear absent. Intuit: Audit log describes application activity. These sources can help locate records and changes, while the proposed identity map distinguishes the underlying source from its imported representations. Keep the original source available for the reviewer.

Compare two fictional patterns

The examples below look similar in a transaction list but require opposite caution. The investigator should preserve the distinction rather than applying a blanket remove duplicates rule.

For the first pattern, the reviewer may authorize an import-record correction after checking the actual history. For the second, removing a row could lose a real event. For the third, keep the case unresolved and obtain the needed source context rather than choosing whichever result makes the count look right.

Inspect batch boundaries and repeated delivery

Check whether imports cover overlapping dates or whether the same file was supplied twice. Compare the batch manifest with the original source rather than relying on filenames, which may change between downloads. Record which entries were actually repeated and which merely fall in the overlapping period.

• Preserve original source references and row context.
• Identify import batches separately from transactions.
• Compare amounts, currencies and date meanings.
• Check existing application states before reimporting.
• Require authorized review before record correction.

An overlapping date range does not mean every entry in that range is duplicated; the imports may contain different subsets. Likewise, a matching source identifier may need context if the source reuses identifiers across accounts. Keep account identity attached to the comparison throughout the investigation.

Verify the corrected representation

After any approved correction, compare the remaining records with the original source population. Confirm that each real event is represented as intended and that no legitimate repeated purchase was removed. Record the implementation and verification evidence under the original exception case.

Use the related workflow guide for the broader exception process and the workflow audit checklist to inspect import-related rework. Test both one-event-two-imports and two-events-one-import examples, since a useful workflow must distinguish transfer duplication from genuine repeated activity.