Avoid duplicate entries when reimporting a bank statement by identifying the account and covered period, checking overlap with earlier imports and comparing transactions using reliable source references and supporting fields. Retain an import log and verify counts and totals after processing. Do not assume the software will recognise every duplicate automatically.
Two identical amounts can be genuine separate transactions, while the same bank movement can appear in overlapping files with a changed narration. Duplicate prevention therefore needs source identity and transaction evidence, not only a rule that deletes matching dates and amounts.
Understand the two layers involved
Consider an illustrative Jaipur building-material supplier importing bank data into its accounting workflow. A bank row can first enter a review or matching area, then be linked to an existing book entry or used to create a new one. The actual stages depend on the chosen system.
A duplicate source row and a duplicate accounting entry are different issues. Removing an extra review row may be enough if no posting occurred. If a second ledger receipt or payment was created, the accounting effect also needs correction through the controlled process.
ICAI's reconciliation and error-correction material supports identifying repeated book entries and correcting their actual effect. A clean imported list is not sufficient if duplicate postings remain in the ledger.
Log each source file before processing
Record bank account, currency, statement start and end dates, download date, file identity, transaction count and who imported it. Keep the original file and any preparation changes. The filename alone may be unreliable because two exports can share a generic name.
Check whether the source period overlaps existing data. Replacing a download after the bank adds late-posted entries may be necessary, but it needs a deliberate comparison rather than importing the entire period again without review.
Avoid maintaining separate uncontrolled import routines for different staff. One person may manually post a receipt while another imports the same bank credit. Clarify who matches existing entries and who is authorised to create new ones.
Work through an overlap example
The supplier first imports 40 transactions covering days 1–15. A later file contains 50 transactions covering days 10–25. Twelve transactions appear in both files.
| Illustrative import count | Transactions |
|---|---|
| First file already processed | 40 |
| Second file received | 50 |
| Confirmed overlapping transactions | 12 |
| New transactions in second file | 38 |
| Unique combined transactions | 78 |
Blindly accepting all rows would produce 90 records instead of 78. However, 12 matching amounts alone do not establish the overlap. Confirm dates, direction, account and references against the original bank source.
Assume the duplicate set contains ₹60,000 credits and ₹25,000 debits. Posting all duplicates would overstate the bank ledger by a net ₹35,000. A correct closing ₹2,00,000 could appear as ₹2,35,000. Counting only net movement can still miss offsetting duplicate errors, so compare gross credits and debits too.
Choose a matching key that reflects the source
A stable bank-issued transaction identifier is useful where available. Retain account, currency, direction, amount and relevant date alongside it. Some exports omit identifiers or supply a reference shared by a group, so verify the field's actual meaning before treating it as unique.
Where no reliable unique reference exists, use a composite comparison and review ambiguous candidates. A customer can make two legitimate ₹10,000 transfers on the same day. Automatically deleting one would create a missing receipt rather than solve duplication.
Preserve identifiers as text. Microsoft documents how automatic spreadsheet conversion can remove leading zeros or alter long numbers. Damaged references can make the same transaction appear different across files or make different references appear equal.
Preview the outcome before posting
Where the workflow offers preview or staging, compare proposed new rows with existing records and inspect exceptions. If those facilities are unavailable, prepare the comparison outside the ledger and use the system's supported import procedure cautiously.
Keep totals for accepted, rejected and deliberately skipped rows. Every source transaction should have a clear disposition. A skipped row should be linked to the existing record that justified exclusion, rather than silently disappearing from the working file.
Do not change source dates or append random text to references to force an import through a duplicate check. That removes evidence and can create the very duplicate the control was meant to prevent.
Correct a completed duplicate import carefully
Identify the affected batch and determine which rows became accounting postings or matches. Preserve the valid original entry and its allocations. If reversal is required, link it to the duplicate rather than deleting an arbitrary same-amount transaction.
Check customer and supplier balances, fees and other counterpart accounts. Reversing only the bank side can leave receivables or payables wrong. Closed or reported periods need the appropriate correction review before historical records are changed.
Rerun the reconciliation after correction and confirm the gross inflow and outflow totals, not merely the final balance. Retain a short incident note explaining the import overlap and the correction references.
Keep legitimate repeated payments reviewable
If two same-value transactions are genuine, retain the evidence explaining why both remain. That note prevents a later cleanup from deleting one simply because it resembles the duplicate pattern that caused the original import problem.
Make reimporting repeatable
Use a consistent account-specific import log and mapping version. Check the next statement opening and closing position, then carry genuine outstanding items forward independently of imported row counts.
A reliable reimport process can accept genuinely new bank information without creating extra accounting movements. The goal is one representation of each real bank transaction, with enough source evidence to distinguish an accidental duplicate from a legitimate repeated payment.